Re: rec i/o and commitment control in websphere

David,

I appreciate the time you have spent looking into these issues.  If you
would indulge me a little further, I would like you to expand on the issue
regarding the toolbox:

Just to make sure we are both on the same wavelength, the native access I am
referring to is not related to the jdbc driver.  I am referring to the
ability of the toolbox rec level i/o classes to access table data using the
direct hooks into the lic code instead of going through the tcp/ip stack if
the class is running on the local as/400.  We see a big speed improvement
when the toolbox rec level i/o bypasses the tcp/ip stack in this manner.

Why doesnt the toolbox rec level i/o use the native access methods (as
defined above) when the userid of the AS/400 object and the job's userid are
not the same?  Are you implying below that using the rec level native access
methods instead of the tcp/ip stack requires that the work has to be done in
the current users job?  This single toolbox requirement is the main
stumbling block keeping us from moving forward.

We are transitioning from sql to rec level i/o slowly.  For some time to
come we will have servlets that have a mixture of SQL and rec level i/o.
This works great for us now as long as the as/400 object userid is not the
same as the jobs userid.  We get commitment control and life is good for
both the rec level code and the sql code.  The only downside is that the
toobox wont use the rec level i/o native access methods if the userid's are
not the same.  As you can see from my benchmark posts several months ago, we
really want the benefit of the native rec level access.

Alex Garrison

----- Original Message -----
From: <dawall@us.ibm.com>
To: <JAVA400-L@midrange.com>
Sent: Wednesday, January 05, 2000 9:27 AM
Subject: Re: rec i/o and commitment control in websphere


> 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
> +---
>

+---
| 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
+---