Re: Server Jobs

["David Morris" <David.Morris@xxxxxxxxxxxxx>]

David,

Thanks for the helpful advice. I have used JDBC quite
a bit for while developing our intranet applications.
We used procedure calls extensively, but passed
messages back through the SQLCA. If JDBC is involved,
a file might be a good way to pass back messages. I
am not sure how I retrieve them though. These would
be diagnotic messages sent from things like CPY,
CRTRPGMOD, CRTJVAPGM, etc.

The tasks I am working on are all iSeries-specific.
The non-specific stuff is what I am building on. On
our system, our pooling is currently at the session
level because we wanted to track users. I recently
completed work to allow a global pool by swapping
profiles or changing effective user and/or groups.
In this case, the environment is very important. A
build may need a library, qtemp, or something else
along those lines.

Thanks for your suggestions, I will start
experimenting.

David Morris

>>> dawall@us.ibm.com 04/02/02 12:20 PM >>>

My personal opinion is it comes down to skills and platform
independence.
If this application will run only to the iSeries and you do not have
JDBC
skills then command call is the way to go.  In your case CC will
probably
be faster and easier to learn.   If you need (or will need in a 'short'
amount of time) this application to run to multiple types of servers
then
it is worth the time to do JDBC and use stored procedures.

One other thought, be careful if you use connection pooling.  Most
connection pooling implementations are refined only to the user level.
Your application is different because it needs job-level refinement.
Suppose you have 10 connections for a specific user in the pool.  Each
connection probably represents a different job on the server.  If you do
work on a connection, put the connection back to the pool, then retrieve
a
connection to do more work, the odds are small that you will get the
same
connection you retrieve the first time.  You have "a" connection for
that
user, but you don't have "the" connection. You will have a different job
so
work previously done on the connection does not show up.

David Wall
Toolbox for Java
iSeries ODBC Driver for Linux