Jesse 1 Robinson wrote:
Looking for a life hack to manage subsystem initialization modules. We recently
discovered that our tape management (HSC/Oracle) SSN init routine was 12 years
out of date. The problem is that the load library itself does not need to be in
link list as it is STEPLIBed to in the HSC proc. But the SSN init routine needs
to be found at IPL time, so we copy it into a link list library. And then
forget about it. One solution it to put the whole load library into link list,
but that seems a bit extreme for all similar products.
Does anyone have a fairly foolproof technique for keeping the SSN init module
up to date short of depending on doc-which will surely get missed somewhere
down the road.
What does the vendor recommend?
My rambling thoughts are these:
For DIY, a ++MOVE usermod will get it on the books so you don't forget
to update the module at system build time, but if the vendor ships JCLIN
to change the module structure, SMP/E will, quite obligingly and without
any fanfare, "put it back where it belongs" on your behalf, and the copy
you are using will be downlevel again.
You could write a usermod with JCLIN to add a part the the module (a
renamed copy of IEFBR14 works fine and takes little or no additional
memory) and a second link step with a SYSLMOD that points where you want
the module to go, making it resident in more than one library. Now,
SMP/E will happily update both copies automagically. But such a usermod
needs to be reworked for every release, and something nagging in the
back of my head says there's another potential pitfall if the vendor
ships service to delete and redefine the load module in a particular way.
You could write a usermod to "repackage" (i.e., include) all the MODs
for the LMOD to change their RMIDs. Future PTFs APPLYs get stopped cold
until the usermod is removed, but you will have to rework it every time
any MOD in the load module is serviced, and this begins to sound a lot
like (*-ick-*) "work."
Any reason not to take the easy way out? Are you short of link list
extents? Alternatively, if it's RENT, you could put the module in MLPA
or Dynamic LPA, if there's room for it (i.e., you're not pushing the
envelope on 24- or 31-bit private), which is sort of drastic (LPA for a
module run once per IPL is overkill in a way) but could be a cheap,
dirty, and durable solution.
--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
