RE: Server Jobs

Lo,

JDBC is an interesting idea. I played
around with it some but I ran into some
problems. Have you used JDBC to run
commands? I tried the easy route and
found that I get a new job for each
call. I could build a server using
JDBC, but I am afraid might run into
the same multi-threaded limitation I
found with CommandCall where you can't
run certain commands in a multi-threaded
environment.

During my testing of JDBC to run
commands, I ran into several other
challenges. The first is getting the
messages back from JDBC. How would
you return diagnostic messages and
error messages? I would be interested
in pursuing this idea, but right now
I see an advantage due to built in
pooling, and a disadvange in message
support.

Thanks,

David Morris

>>> Lo.Raikov@MISYS.COM 04/01/02 17:56 PM >>>
Why not use JDBC? It's portable, it's consistent, one is free to use his
preferred connection pooling classes. This "specialized environment "
will
be maintained in the JDBC background job; just use a wrapper technology
to
invoke the CL commands you want on each call.

Lo