Re: rec i/o and commitment control in websphere

[dawall@xxxxxxxxxx]

The result of my research.   There are really two points of discussion
here:

1) Commitment control:
   When you use the AS/400's native JDBC driver, from a database point of
   view you are putting your job in 'server mode'.  Server mode means you
   have delegated all SQL work to another job.  Another ramification is
   that a job cannot start commitment control once in server mode.  Native
   record-level access calls database APIs to carry out db tasks.  These
   APIs are in the current job.  This does not work since native JDBC put
   the job in server mode.

   This is working as designed.  Server mode processing is an alternative
   to the standard way the AS/400 has always handled transaction
   processing.  It is designed to work in the industry standard way.
   Obviously, not everyone wants to process in that way (the AS/400
   processing model has its advantages - Record I/O being in the
   forefront), but there is no way to merge the two processing models that
   is feasible to implement.  IBM's stated direction is that of the
   industry so it is unlikely that a solution that merges these models will
   come along in the future.

2) Toolbox perform tasks in the current job even when the job's UserID does
not match the UserID assigned to the AS400 object:
   We are looking at this but don't look for any change in this behavior
   soon.  There is a lot of bookkeeping and authentication involved with
   allowing work in the current job when UIDs don't match, and we won't do
   anything until we look at all of the possible security holes and how to
   prevent them.  Until then, the easiest way to stay in the current job is
   to create the AS400 object using the default constructor -- AS400 system
   = new AS400();  When on the AS/400, the toolbox will assume the request
   goes to the current AS/400 using the current job's identity.

David Wall
AS/400 Toolbo for Java

"Alex Garrison" <agarrison@logtech.com> on 12/30/99 12:03:40 PM

Please respond to JAVA400-L@midrange.com

To:   JAVA400-L@midrange.com
cc:
Subject:  rec i/o and commitment control in websphere




Here is an interesting problem several of us have been wrestling with this
week:

1. In order for record-level i/o using the IBM Java toolbox to use the
native access paths in websphere servlets on an as/400, you have to use
usrprf QTMHHTTP in the toolbox connection. (This was covered in my email
several weeks ago.  The bottom line was the websphere instance runs under
QTMHHTTP and the toolbox native access requires the connection to use the
same usrprf as the job in which it is running.)

2. If you want to use commitment control with your record-level i/o in
websphere, you will have to use any usrprf EXCEPT QTMHHTTP.  If we use
usrprf QTMHHTTP and try method
KeyedFile.startCommitmentControl(KeyedFile.COMMIT_LOCK_LEVEL_ALL), we get a
"CPF8366 Commitment definition *N not created" message.  If you use any
other usrprf, the commitment control works fine - commits, rollbacks,
everything.

Problem #2 seems to be tied to how sql server mode works?  Maybe there is
something I can put in a websphere properties file?

The ideal solution seems to be for the toolbox to remove the restriction
that the toolbox userid must match the userid of the job in which it is
running to use the native access methods instead of going through the
tcp/ip stack.  This requirement seems overly restrictive to me.  Once the
toolbox recognizes that it is running locally on an as/400, it should use
the native access methods, period (unless I specify
AS400.setMustUseSockets(true)).  Why should it matter what userid I am
using in the toolbox?

Any thoughts?  Has anyone else run into this problem?


Alex Garrison
agarrison@logtech.com
(423)636-7213






+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---