> -----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.
Thanks,
-jc-
----------------------------------------------------------------------
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
