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
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.
On Wed, Apr 2, 2014 at 10:20 AM, Chris Bipes <chris.bipes@xxxxxxxxxxxxxxx>wrote:
I totally agree with the negative impact of setting the number of uses to
one. Don't want to but I have these land mines sitting out there just
waiting for the next job to step on. We have identified the connection
that was specifying the libraries parameter and messing up the jobs library
list. Tonight we will install the change to Not use the libraries
parameter but instead qualify the library of the file to update. Also to
use the correct user ID with an updated job description. That should stop
more land mines from being planted.
Director of Information Services
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:
midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Mike Cunningham
Sent: Tuesday, April 01, 2014 6:13 PM
To: Midrange Systems Technical Discussion
Subject: RE: QZDASOINIT prestart job tuning
I think setting the uses to 1 is going ti have an impact on overall system
CPU use. I think initial job startup is one of the more resource intensive
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