'Override' libraries give me the willies. War story. Shortly after I started here, VTAM would not come up one Sunday after a maintenance IPL. Turned out that some modified VTAM module(s) had been placed 'temporarily' into an override library for testing and promptly forgotten about. The perp had a note *in plain sight* on his wall to remind him of this maneuver. It had been there so long that he no longer saw it (!). Willies, I tell you.
. . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Thursday, September 21, 2017 9:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Keeping SSN init modules current On Thu, Sep 21, 2017 at 11:16 AM, Tom Marchant < 0000000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote: > On Thu, 21 Sep 2017 02:29:11 +0000, Jesse 1 Robinson wrote: > > >What if we created something like this: > > > >++USERMOD (HSCxxxx) REWORK(date) . > >++VER (Z038) FMID (hsc-fmid) . > >++MOVE (ssn-init-module) SYSLIB(hsc-loadlib) TOSYSLIB(LINKLIB) LMOD . > > > >where LINKLIB is SYS1.LINKLIB. > > I don't like it. Which SYS1.LINKLIB? The one on your current IPL > volume? Or do you have a single target zone where you always apply > maintenance, with a VOLSER that never changes? > > A better choice, IMO, is a new data set that you create for this > purpose. Or perhaps you have an installation library that makes sense > to add to LNKLST. > > Also, rather than ++MOVE, you can add a second SYSLIB for that module. > > I don't see the disadvantage of adding the load library to LNKLST. > Are you approaching the 255 extent limit for LNKLST? I believe that > with LLA and VLF it is no longer necessary to be concerned about the > performance of LNKLST with a large concatenation. > > -- > Tom Marchant > What I have in my linklist PROGnn member starts like: SYSLIB LINKLIB(SYS1.&SYSNAME..LINKLIB) SYSLIB MIGLIB(SYS1.MIGLIB) SYSLIB CSSLIB(SYS1.CSSLIB) SYSLIB LPALIB(SYS1.&SYSNAME..LPALIB) /* START THE ACTUAL LINK LIST */ LNKLST DEFINE NAME(LNKLST00) /* GIVE THE LINK LIST A NAME */ LNKLST ADD NAME(LNKLST00) DSN(SYS1.&SYSNAME..LINKLIB) LNKLST ADD NAME(LNKLST00) DSN(SYS1.LINKLIB) My LPALSTnn starts with: SYS1.&SYSNAME..LPALIB, SYS1.LPALIB, ISF.SISFLPA, Each z/OS image has it's own, "private", LPALIB & LINKLIB which are the very first in their respective lists. I keep _all_ the vendor LPALIB resident modules in the SYS1.&SYSNAME..LPALIB library. I keep all the "override" and "in house" LINKLIST members in SYS1.&SYSNAME..LINKLIB. By "override", I mean when I or a vendor wants to "replace" an IBM module. -- *L'Shanah Tovah Tikatevu* Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
