Re: frequent manipulation of jobs library list

Not knowing anything about the app makes this hard to answer.
For a interactive app, greenscreen or web/cgi app, changing libl is not a big deal,
if your version of high volume is interactive.
If batch, as others have said, it can be a heavy hit, unless you do something like the queue suggestion, only have a servicing pgm for each libl, or even a subsystem for each libl, and have a pgm that directs traffic.
In some systems we pass the files lib & pgm lib as parms, and every
pgm is called with the library name and every file has an ovrdbf.
Ovrdbf should cost you nothing compared to changing libl or curlib.
Calling pgms w/library specified keeps someone from injecting another
version into the library list from ever getting called.
Jim Franz
----- Original Message ----- From: <joe.goray@xxxxxxxxx>
To: <midrange-l@xxxxxxxxxxxx>
Sent: Wednesday, December 23, 2009 11:55 AM
Subject: frequent manipulation of jobs library list

Is there any impact or considerations related to constantly changing a
jobs library list, either by adding/removing a library or by changing the
curlib?

We are trying to develop a methodology for providing a "beta" environment
based on a facility number. One idea is to create a set of beta libraries
where beta code will be installed. Based on a control file that would
contain facilities included in the beta. If they are a beta facility, the
beta library would be added to the top of the libl (or made the curlib).
If it's not a beta facility, the beta library will be removed from the
libl.

Our processes don't process data by facility, so this approach would
likely be changing the libl every transaction, which is high volume. Some
of these processes run 24X7.

Would manipulating the library list this frequently impact job performance
and/or system performance?

Thanks
Joe
--
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,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.