Re: Native JDBC Driver and Library List Problems -- JAVA400-L

Thanks to Richard Dettinger and Jim Mason for their responses.  

Jim's first option will not work for me because I need multiple libraries added 
to the library list.  

In the Native JDBC Driver FAQ is states that the libraries property actually 
only allows only one library.  The FAQ reads as follows:

>>This property is a little deceptive. It's name implies that it is plural, but 
>the native JDBC driver only allows one library to be specified. >>That one 
>library, if provided will be set as the default library. This default library 
>will be used as the intended library for all references in >>SQL statements 
>that are not qualified. 
>>The "naming" property has an effect on how this property will work if it is 
>not explicitly set. In the default case, where "naming" is set to >>"sql", 
>JDBC works like ODBC. The default library is the same name is the user 
>profile. If the case where "naming" is set "system", the >>default library 
>will be the top library in the users library list. There are restrictions on 
>how this work. See the entry on using a library list >>found elsewhere on this 
>site. 

I tried option 2 anyway but still was unable to locate files that should have 
been in the library list.

So I guess we'll try option #3 which should work for us.  As you can probably 
tell, I am a java person, not an AS400 person but I'm learning fast.  

I hope IBM comes up with a better solution in the long run. Thanks to everyone 
for their input on this issue.   

Alan A. Heitkamp
H.B. Fuller Company
(651) 236-4072
Al.Heitkamp@hbfuller.com


>>> <cujo@us.ibm.com> 08/25/00 09:08AM >>>
Sorry you are having problems with this.  It is something that comes up for
us every six months or so.  You are right, the actual library list is not
used.  The library list for the user, based on the job description is.  I
don't remember the details on why that was (it is further down in the
system), but I have requested the change in the past and never been able to
convince people that it is feasible and the right trade off to make.  I
guess there is more too it than meets the eye.

The one issue I think I had with what you said is that they QSQSRV (they
are actually QSQSRVR jobs) job doesn't show up in WRKACTJOB at the time of
the error... it actually does.  You should be able to find the job under
the QSYSWRK subsystem as long as you have not closed the connection.  Once
you close the connection, the 'active' jobs goes back into a 'prestart'
pool for reuse (normally that is, sometimes it really does go away), and it
doesn't show up under WRKACTJOB anymore.  If you have several database
connections, there will be several QSQSRVR jobs running in QSYSWRK.  You
can figure out which is the right one for your job by looking and your
joblog from your Java program that is running.  It will say something like
'Job XXX used for server mode processing'.

Jim Mason sent a note that I got this morning making some suggestions on
how to deal with the issue.  The first two suggestions he put forward are
really the same, just specified differently.  This will work as long as you
are interested in a specific library that is different.  Then you can
specify a default library and it should be used.

The third suggestion should work because it sets the library list for the
QSQSRVR job *after* the database connection has been established and the
initial library list has been picked up.

One more issue:  The two concepts of default library and library list are
mutually exclusive and based off of the 'naming' mode.  For example, if you
specify SQL naming (the default), there is no such thing as a library list.
SQL naming uses the default library.  If you specify system naming, the
default library is ignored and the library list is used.  This is why there
are not issues to resolve like 'Which will get used?  The cur lib from the
library list or the default library.'  It depends on your naming mode.

Hope this helps some.  I wish it was more obvious and always did exactly
what people would want, but I hope you agree that the solutions are
somewhat reasonable.  If you don't agree, send me e-mail and we can talk
about it further.

Regards,

Richard D. Dettinger
AS/400 Java Data Access Team

"TRUE! nervous, very, very dreadfully nervous I had been and am; but why
WILL you say that I am mad?
The disease had sharpened my senses, not destroyed, not dulled them. "

- Edgar Allan Poe
"The Tell-Tale Heart"




"Al Heitkamp" <Al.Heitkamp@hbfuller.com> on 08/24/2000 03:27:23 PM

Please respond to JAVA400-L@midrange.com 

To:   Java400-L@midrange.com 
cc:
Subject:  Re: Native JDBC Driver and Library List Problems




Thanks to Arlene Soderlund for her suggestion but unfortunately,  it does
not correct my problem.  The command I used is as follows:

SBMJOB CMD(CALL PGM(HEITKA01/IMINTCL)) JOB(IMINTCL) JOBD(HEITKA01/IMINT)
INLLIBL(*JOBD)

Using WRKACTJOB, I verified that the IMINTCL job has the correct library
list.  In addition I also verified that the QJVACMDSRV job that is spawned
also has the correct library list.  My java program calls DB2 stored
procedures, so a third job called QSQSRV running as QUSER is spawned and I
suspect that this is the component that is not getting the library list
from what is specified on the SBMJOB command.  I get error CPF4101 because
the stored procedure is trying to access a file not in the library list.
The QSQSRV job does not appear in the WRKACTJOB list when this error occurs
so I can not actually see the library list.

If I change my user profile to point the job description using "CHGUSRPRF
USRPRF(HEITKA01) JOBD(HEITKA01/IMINT)", then submit the job it works fine.

Any help would be greatly appreciated.

Thanks,


Alan A. Heitkamp
H.B. Fuller Company
(651) 236-4072
Al.Heitkamp@hbfuller.com 


>>> "Arlene M Soderlund" <Arlene_M_Soderlund/NFCNA.COM@nfcna.com> 08/23/00
02:33PM >>>








"Al Heitkamp" <Al.Heitkamp@hbfuller.com> on 08/23/2000 10:02:23 AM


SBMJOB CMD(CALL PGM(STERMB01/MF4000CL)) JOB(MF4000CL)
JOBD(HEITKA01/AAHJOBD)
INLLIBL(*JOBD)
SBMJOB CMD(CALL PGM(HEITKA01/IMINTCL)) JOB(IMINTCL) JOBD(HEITKA01/IMINT)
INLLIBL(*JOBD)


add Inllibl to the submitt






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



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