Db2 for z/OS & Db2ZAI

Saw this some weeks back and thought it was an interesting question.  Something that I'm also not accross.  How did this go for you?  Did you progress???

We ran like this for a while on one of our sysplexes. Our zOS guys were responsible for installing IBM Content Manager, and they wanted all of THEIR code to be in the linklist and in LLA/VLF, so since they were maintaining the stored procedure address spaces for that product, they also wanted our Db2 SDSNEXIT/SDSNLOAD in the linklist and in LLA.

We still run that sysplex, but we no longer have the Db2 libraries in the linklist/LLA. 

Whether or not you get any real benefit from it would depend on your specific environment. If you're noticing batch jobs/STCs taking a long time to start up, or RMF is showing you a lot of I/O time on those libraries, putitng them in LLA could help that, yes. If you have a lot of tasks stopping and starting at the same time, or batch jobs constantly firing off, having the modules coming from memory might be a good idea.

But most of the modules in those libraries are loaded into memory one time per process, when the process first starts and connects to Db2...and a lot of those modules are only loaded by the subsystem itself. Allied processes typically need to load primarily the language interface. You'd need to be a "special case" to really see any benefit from reducing I/O against the loadlib.

If you do this, make sure to over-allocate the size of your SDSNLOAD and SDSNEXIT. The linklist and LLA have real issues if a library goes into extents, especially while Db2 is "live". If you need to re-size, move, or otherwise "manage" those libraries in any way, you will need to STOP LLA and deallocate the libraries from linklist to make those changes, then either re-allocate them, or IPL.

The contents of SDSNLOAD will change every time you do maintenance or perform an upgrade. SDSNEXIT will change whenever you re-assemble exits or change your ZPARMs. Which should NOT be often. But you will have to issue a F LLA,REFRESH or F LLA,UPDATE to make sure that the pointers are updated. Not a big deal.

Having the libs in the linklist/LLA means that none of your applications need to STEPLIB or JOBLIB to them...they can load the Db2 code from there when they attach. This makes things simple for them...if you only have one Db2 subsystem/environment on the LPAR. If you have multiple Db2 environments/subsystems on a single LPAR, then you run the risk of an application trying to connect to DB2A, but loading the code from DB2B from the linklist, if they don't have the appropriate STEPLIB. Usually not an issue for simple programmatic stuff...the LI rarely changes. But there are some utilities that require matching code in the subsystem loadlib and the job loadlib.

Long story short...we ran like that for a while, and it worked fine...but after several years it just became a pain to have a special footnote in maintenance procedures, "remember to refresh LLA if you're on system A, B, or C!", and we really weren't seeing a huge benefit in terms of I/O, so we took those libraries out of linklist/LLA, and it still works fine.

-Mark

------------------------------
Mark Wieczorkowski
------------------------------