I think he might also want to check that he is using the IBM JDBC driver for linux. Other JDBC drivers may not work exactly the same as the IBM provided one.
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Chris Bipes
Sent: Wednesday, April 02, 2014 10:52 AM
To: 'Midrange Systems Technical Discussion'
Subject: RE: QZDASOINIT prestart job tuning
You just hit the nail on the head. Yes the programmer is using an application pool. Now for the funny part, the connections are all being used by other applications and servers so when his app runs in the morning, he has no available connections and it crashes. So since I am not a JAVA programmer and the programmer in question is not an iSeries programmer, how can we define the connection for a Red Hat Linux 6 server running Tomcat and a JAVA application? He is using a JDBC connection and when he gets in I will ask what tool kit he is using to establish the connection. I believe it is from the JT400 but I will not swear to it.
Director of Information Services
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Charles Wilt
Sent: Wednesday, April 02, 2014 7:40 AM
To: Midrange Systems Technical Discussion
Subject: Re: QZDASOINIT prestart job tuning
I think you're missing something somewhere...
My understanding is that when a job is reused, it is reset. This should include the library list.
Sounds like you've got a connection pool on the app side that isn't actually releasing the job for reuse on the i side. Note that this also means that changing reuse to 1, won't have an effect.
And the connection pool isn't handling the differences in connection properties right.
I've heard of funny issues when you inadvertently have multiple layers of connections pools. For example, connection pools in a Java app itself along with another layer of connection pools in the application server.
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l