James, I saw this inquiry on Midrange-L, as well. From there it looks like you're trying to access database tables (*FILE objects in a *LIB object) as opposed to files, which on this forum tends to refer to IFS stream files.
How are you trying to access the tables. Through JDBC using the JDBC driver from JT400? Are you using JT400 or JT400Native? What does your connection url look like? One of the important things to remember is the userid and password for the connection are in this url in most circumstances. The userid under which the JVM running Tomcat is running has no bearing on the database connection unless you're running JT400Native.
If you're running JDBC through JT400, there should be info in the joblogs for the QZDASOINIT job that is serving your connection. That job log will have info about why the file couldn't be found (no privilege, etc.). Use WRKOBJLCK xxx *USRPRF where xxx is the user in the JDBC connection string to find the QZDASOINIT job. You can add "server trace=4;" to the connection string to get database debug info in the job log. "server trace=12" will turn on debug in the QZDASONIT job and change the job logging to save the job log when the job finishes.
At V5R2 the recommendation from IBM was to run JT400Native when Java and database were on the same box. Since V5R4 or so, I've had better results running JT400. Part of the "better" in that statement is that I can troubleshoot issues like this more easily. It also seems to return results just as fast or faster. All of that depends on the configuration of the box, of course. One advantage of the JT400 approach is that the database jobs are working in a different subsystem from the jvm which may involve different memory pools and an opportunity to optimize multiproccessor usage.
-----Original Message-----
From: java400-l-bounces@xxxxxxxxxxxx [mailto:java400-l-bounces@xxxxxxxxxxxx] On Behalf Of James Lampert
Sent: Thursday, December 08, 2011 6:58 PM
To: Java Programming on and around the IBM i
Subject: Can anybody suggest any reasons why BIRT would be unable to establish a JDBC connection, when running on the same physical box?
Thanks again for all who had suggestions on the "Java not where Tomcat is expecting to find it" issue; we've resolved it, using the QOpenSys locations.
We have another situation at a customer.
BIRT, running in a webapp under Tomcat, is unable to access files on the same box that it's running on (using the TCP Loopback address).
Any suggestions on places to look for the cause?
--
JHHL
--
This is the Java Programming on and around the IBM i (JAVA400-L) mailing list To post a message email: JAVA400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/java400-l
or email: JAVA400-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/java400-l.
midrange.com
