Hi Scott,
I'm glad you did suggest something obvious -- I did think of the
authority, but not the SQL server jobs' library lists being different.
The jobd specified on my user profile on boxA was different than on
boxB. I noted that on the box where it worked, my user profile jobd had
the correct library list, and that was used regardless of what my job's
library list was.
A more long-winded explanation follows: the java program SQL2JXLJ has
the following two lines:
jdbcDriver = "com.ibm.db2.jdbc.app.DB2Driver";
jdbcConnection = "jdbc:db2://localhost";
According to
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp?topic=/rzahh/page1.htm
<quote>
The simplest form of JDBC URL is a list of three values that are
separated by colons. The first value in the list represents the protocol
which is always jdbc for JDBC URLs. The second value is the subprotocol
and db2 or db2iSeries is used to specifiy the native JDBC driver. The
third value is the system name to establish the connection to a specific
system. There are two special values that can be used to connect to the
local database. They are *LOCAL and localhost (both are case
insensitive). A specific system name can also be provided
</quote>
Ok, so it's connecting to the local system. It further says
<quote>
[One] way to specify properties is to place them in a list on the URL
object itself. Each property in the list is separated by a semi-colon
and the list must be of the form property name=property value. This is
just a shortcut and does not significantly change the way processing is
performed
</quote>
A list of the properties that can be specified is here:
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/rzaha/conprop.htm
<quote>
libraries
A space-separated list of libraries. (A list of libraries can also
be separated by colons or commas.) This property allows a list of
libraries to be placed into the server job's library list or a specific
default library to be set.
The naming property affects how this property works. In the default
case, where naming is set to sql, JDBC works like ODBC. The library list
has no effect on how the connection processes. There is a default
library for all unqualified tables. By default, that library has the
same name as the user profile that is connected. If the libraries
property is specified, the first library in the list becomes the default
library. If a default library is specified on the connection URL (as in
jdbc:db2:*local/mylibrary), that overrides any value in this property.
In the case where naming is set system, each of the libraries
specified for this property is added to the user portion of the library
list and the library list is searched to resolve unqualified table
references.
</quote>
However, SQL2JXLJ did not specify a "libraries" property on its
connection string, which implies it would simply use the library list of
the QSQSRVR job. So it would appear that the QSQSRVR job itself sets
the library list based on the connecting user's user profile jobd.
It seems I could modify SQL2JXLJ to grab my job's current library list
and pass it as part of the connection string, but I'm not sure if that
would override the apparent behavior of the QSQSRVR job. Something else
to test in my spare time...how do I get the current library list in a
java program?
*Peter Dow* /
Dow Software Services, Inc.
909 793-9050
pdow@xxxxxxxxxxxxxxx <mailto:pdow@xxxxxxxxxxxxxxx> /
I'm pretty sure
Scott Klement wrote:
Peter Dow (ML) wrote:
ERROR: PHPLOCN in *LIBL type *FILE not found.
Java program completed with exit code 1
I hate to suggest something this obvious, but... is it possible that the
SQL server jobs on the two systems have different library lists?
Or that the user profile who is executing the SQL statement doesn't have
authority to the file on one system, but does on the other?
It seems likely that Peter has already thought of these things and tried
them -- but surely this makes more sense than checking CCSIDs and
national language versions?!
midrange.com
