So if you had put the module on your sandbox, then this thread probably would not exist?
Don Imbriale On Wed, 26 Jul 2006 14:07:29 -0500, Chase, John <[EMAIL PROTECTED]> wrote: >> -----Original Message----- >> From: IBM Mainframe Discussion List On Behalf Of Walt Farrell >> >> [ snippage ] >> >> First, the flavor of IKJEFTSR that can run code authorized >> can not find things in ISPLLIB, and has never had the ability >> to find things there. >> A form of invocation for IKJEFTSR that would search ISPLLIB >> exists, but it can not invoke authorized code. >> >> Therefore, if this worked previously via IKJEFTSR you must >> have had another copy of the module somewhere in LINKLIST or >> LPA, or you must have had a STEPLIB or TSOLIB. > >Discussed this in our staff meeting today, and best I can surmise based >on available evidence and documentation, and the means by which we >propagate maintenance across the sysplex, this is the most plausible >sequence of events: > >0. For this illustration let's say we run three z/OS images in a >Parallel Sysplex. Let's call them "Production", "Development" and >"Sandbox". > >1. Each z/OS image owns a pair of "SYSRES sets"; let's call them PRI >and ALT. Each dataset that resides in the "SYSRES sets" has a SYS1 hlq >and is indirectly cataloged. > >2. We have an installation-defined load library that is both >APF-authorized and link-listed; let's call it SYS1.COMPANY.LOADLIB. >This load library resides in the "SYSRES set" on each image. > >3. We installed the DocuText product in the Development image, and >later propagated it to the Production image. Note that it was never >installed into the Sandbox image. > >4. In accordance with the product installation doc, we apparently chose >the option to copy the D00YAAI authorized load module into each instance >of SYS1.COMPANY.LOADLIB on the Development and Production images (but >NOT on Sandbox, since we didn't intend to run it there). Everything >worked as expected. > >5. Priorities got changed, we played some "musical chairs", and the >"official rollout" of the product got postponed. > >6. In preparation for events occurring now, at least two "maintenance >cycles" were applied to z/OS. Maintenance is initially applied to the >ALT RES set on Sandbox, while it is IPLed from its PRI set. Sandbox is >then IPLed from its ALT set, and initial "smoke-testing" of the applied >maintenance is done. > >7. When we are satisfied that the maintenance didn't "break" anything, >it is propagated to the Development image via full-volume COPY from the >Sandbox ALT RES set to the Development ALT RES set (Development is >running on its PRI set when this is done). Note that the copy of >SYS1.COMPANY.LOADLIB on Development's ALT RES set will NOT contain the >D00YAAI load module. Development is then IPLed from its ALT RES set. > >8. By this time the "official rollout" of the DocuText product has >"fallen off the back burner" into the "pile of stuff we gotta do when a >burner becomes available again". Accordingly, nobody thought to >exercise it with the z/OS maintenance. > >9. After a suitable "shakedown" period, the maintenance is propagated >to Production via the same technique described in #7. Now another >instance of SYS1.COMPANY.LOADLIB is missing the D00YAAI load module. > >A. After a suitable period of running Production with the maintenance, >the decision is made to "normalize" the RES sets to prepare for the next >maintenance cycle. "Normalization" is done by full-volume copy of each >image's ALT RES set to its respective PRI RES set. Each image is >subsequently IPLed from its PRI RES set. By this time, there is no >longer a copy of SYS1.COMPANY.LOADLIB that contains the D00YAAI load >module. > >B. The time arrived to list all software products we need to migrate to >the new infrastructure and test. DocuText was "rediscovered", so after >verifying that we are current on our DocuText license, I tried to run >it. The results of that attempt gave birth to this thread on IBM-MAIN. > >> As for "program not found" vs "program not authorized" I >> believe you'll find that "program not found" means exactly >> that: no copy of the program was found. >> >> "Program not authorized" means, as far as I know, that a copy >> was found, but not in an authorized library. If IKJEFTSR >> could search ISPLLIB, and if ISPLLIB contained unauthorized >> libraries, then I agree that you should have seen a 56 reason >> code. But as IKJEFTSR can not see ISPLLIB, the 40 was correct. > >I understand now. This illustrates why we generally try to avoid having >multiple copies of a load module in different libraries. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
