Re: Monday blues? (IKJEFTSR RC=20,RSN=40)

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Imbriale, Don
> 
> So if you had put the module on your sandbox, then this 
> thread probably would not exist?

Probably not.

-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

Re: Monday blues? (IKJEFTSR RC=20,RSN=40)

[Imbriale, Don]

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

Re: Monday blues? (IKJEFTSR RC=20,RSN=40)

[Chase, John]

> -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

Re: Monday blues? (IKJEFTSR RC=20,RSN=40)

[Walt Farrell]

On 7/24/2006 3:52 PM, Chase, John wrote:

-Original Message-
From: IBM Mainframe Discussion List On Behalf Of McKown, John

Any chance that ISPLLIB (and maybe STEPLIB?) could contain an 
non-APF authorized library? IIRC, that will remove the APF 
authorization from all modules loaded via ISPLLIB regardless 
of the AC value.


No //STEPLIB in the logon proc, and about half of //ISPLLIB is
unauthorized (and it's always been that way, AFAIK).

Besides, if it were an authorization problem I'd expect a different
diagnostic than "program not found".  Of course, this is TSO and
ISPF


And you also wrote earlier:

There are unauthorized libraries in the //ISPLLIB concatenation.  But if
it's an authorization issue, why does the reason code translate to
"program not found" (reason code 40 (x'28')) instead of something like
"program not authorized"  (reason code 56 (x'38'))?


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.


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.


Walt Farrell, CISSP
z/OS Security Design, IBM

--
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

Re: Monday blues? (IKJEFTSR RC=20,RSN=40)

[Andy Wood]

On Tue, 25 Jul 2006 11:37:03 -0500, Chase, John <[EMAIL PROTECTED]> wrote:

>
>I added the product's load library to the //STEPLIB in our TSO logon
>proc.  And pursuant to Tom Conley's comment regarding STEPLIB vs
>LINKLIST, I will likely seek "internal consensus" to linklist it
>instead.
>

Did you check the Docu/Text install guide? In the Jobscan install guide it 
says this about the similar module: "Move module J00YAAI to an APF-
authorized data set. If the data set is not in the LNKLST or in LPA, it 
must be added to the STEPLIB concatenation in the TSO Logon PROC. It will 
not be loaded from the ISPLLIB allocation."

Is it possible somebody followed advice like that and copied D00YAAI to 
somewhere where it got lost in your maintenance process?
 

--
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

Re: Monday blues? (IKJEFTSR RC=20,RSN=40)

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Matthew Stitt
> 
> However, you have now left us with a mystery. 
> 
> What happened to solve your problem?

I added the product's load library to the //STEPLIB in our TSO logon
proc.  And pursuant to Tom Conley's comment regarding STEPLIB vs
LINKLIST, I will likely seek "internal consensus" to linklist it
instead.

-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

Re: Monday blues? (IKJEFTSR RC=20,RSN=40)

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Mark Zelden
> 
> On Tue, 25 Jul 2006 10:10:08 -0500, Chase, John wrote:
> 
> >Correct.  "Sandbox" gets the maintenance first, and its "alternate"
RES 
> >set has already been prepped for z/OS 1.7.
> 
> Unfortunate you only appear to have 2 sets.  What if you need 
> to put on maintenance for z/OS 1.6 again? 

That would depend on whether such need (and it would have to be a "real
need") occurs before or after we migrate to the new hardware.  I.e., we
have no more preventive maintenance cycles scheduled until after
migration is complete.  If "after", we would probably have enough spare
DASD to clone another "alternate" set from the Production
pre-maintenance set (provided we haven't "normalized" Production by
then).  Otherwise we'll just have to cross that bridge if we come to it.

> >> Could this module have been in a local lnklst lib before and
perhaps 
> >> someone did some cleanup?
> >
> >I can't say definitively that that's not possible (that's as close as
I 
> >can come to saying, "No way, Jose").  The only comment in the 
> >maintenance log of the PROGnn member about DocuText was its addition
to 
> >the APF list in Sept. 2005, and that comment log dates back to when
we 
> >upgraded from z/OS 1.4 in Feb. 2004.
> 
> I was talking about module deletion from an existing LNKLST 
> library, not removing an entire library from the LNKLST.  SMF 
> might have a trail if that was the case. 

We try to avoid "extra copies" of load modules; especially of software
products.  Too easy to forget they're "lying around".

> Even though your sandbox has the same level of z/OS 1.6 or 
> can IPL under z/OS 1.7, did it break there also? Or don't you 
> have the product installed there?

Actually we're still on z/OS 1.5 (on G5 hardware) at the moment.  But
no, we don't have this product installed in the "sandbox" anyway.

-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

Re: Monday blues? (IKJEFTSR RC=20,RSN=40)

[Matthew Stitt]

However, you have now left us with a mystery. 

What happened to solve your problem?

--
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

Re: Monday blues? (IKJEFTSR RC=20,RSN=40)

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Pinnacle
> 
> > Since there seems to be a consensus here, I added the Docu/Text load

> > library to //STEPLIB of the logon proc  Now it works again.
> >
> > [ snip ]
> 
> John,
> 
> Did you remove the module from your LINKLIST? 

AFAICD it was never in the linklist (only in the APF list), so "no".

> LINKLIST is 
> always the best way to resolve the STEPLIB issue.  STEPLIB is 
> very bad for your TSO performance since that library is 
> search every single time you hit enter.

Noted.

> PS - You stopping by Baltimore? 

Not this time  We're in the midst of a **MAJOR** infrastructure
upgrade, which will be followed "immediately" by a z/OS upgrade.  We
sent a contingent to Spring SHARE in Seattle, and we're busy applying a
lot of what they brought back from there.

Maybe when all the dust has settled, we could cobble up a SHARE pitch on
"How to Build an Orange Crate from Old Pieces of Furniture"[1] or
something.  :-)

-jc-

[1] From the Library of Congress :

LC Control Number: 57006308  
Type of Material: Book (Print, Microform, Electronic, etc.) 
Brief Description: Cluett, Jack. 
 How to build an orange crate from old pieces of furniture. Illus. by
Tom Funk. 
 [1st ed.] 
 Garden City, N.Y., Doubleday, 1957. 
 189 p. illus. 22 cm. 
  
CALL NUMBER: PS3505.L97 H6 

--
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

Re: Monday blues? (IKJEFTSR RC=20,RSN=40)

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of John P Kalinich
> 
> On July 25, 2006, Mark Zelden wrote:
> 
> >Could this module have been in a local lnklst lib before and perhaps 
> >someone did some cleanup?
> 
> Or could the load library have been TSOLIB'd in a TSO startup 
> clist (PARM= in the logon procedure)?

To this I can definitively say "No".

-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

Re: Monday blues? (IKJEFTSR RC=20,RSN=40)

[Mark Zelden]

On Tue, 25 Jul 2006 10:10:08 -0500, Chase, John <[EMAIL PROTECTED]> wrote:

>
>Correct.  "Sandbox" gets the maintenance first, and its "alternate" RES
>set has already been prepped for z/OS 1.7.
>

Unfortunate you only appear to have 2 sets.  What if you need to put
on maintenance for z/OS 1.6 again?  

>> Could this module have been in a local lnklst lib before and
>> perhaps someone did some cleanup?
>
>I can't say definitively that that's not possible (that's as close as I
>can come to saying, "No way, Jose").  The only comment in the
>maintenance log of the PROGnn member about DocuText was its addition to
>the APF list in Sept. 2005, and that comment log dates back to when we
>upgraded from z/OS 1.4 in Feb. 2004.
>

I was talking about module deletion from an existing LNKLST library,
not removing an entire library from the LNKLST.  SMF might have a
trail if that was the case.  

Even though your sandbox has the same level of z/OS 1.6 or can IPL
under z/OS 1.7, did it break there also? Or don't you have the product 
installed there?

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group
mailto: [EMAIL PROTECTED]
z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

--
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

Re: Monday blues? (IKJEFTSR RC=20,RSN=40)

[Pinnacle]

Since there seems to be a consensus here, I added the Docu/Text load
library to //STEPLIB of the logon proc  Now it works again.

**BUT**

I checked archived copies of our logon proc dating back to the original
installation of Docu/Text here, and its load library has NEVER been in
the //STEPLIB concatenation; only in //ISPLLIB.  And the only thing
that's changed since the Docu/Text installation is the maintenance level
of z/OS 1.5 that we're running.

Anyway, "problem solved" so thanks for all the ideas, etc.



John,

Did you remove the module from your LINKLIST?  LINKLIST is always the best 
way to resolve the STEPLIB issue.  STEPLIB is very bad for your TSO 
performance since that library is search every single time you hit enter.


Regards,
Tom Conley

PS - You stopping by Baltimore? 


--
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

Re: Monday blues? (IKJEFTSR RC=20,RSN=40)

[John P Kalinich]

On July 25, 2006, Mark Zelden wrote:

>Could this module have been in a local lnklst lib before and perhaps
>someone did some cleanup?

Or could the load library have been TSOLIB'd in a TSO startup clist (PARM=
in the logon procedure)?

Regards,
John Kalinich
Computer Sciences Corp

--
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

Re: Monday blues? (IKJEFTSR RC=20,RSN=40)

[Debbie Mitchell]

__

Is it possible that the module in question was included in a linklisted 
library that was replaced with the recent maintenance?  Possibly 
SYS1.LINKLIB or one of its cohorts?  Just a thought.

Debbie Mitchell
Utica National Insurance Group


> 
> On Tue, 25 Jul 2006 09:38:29 -0500, Chase, John wrote:
> 





> Could this module have been in a local lnklst lib before and 
> perhaps someone did some cleanup?

I can't say definitively that that's not possible (that's as close as I
can come to saying, "No way, Jose").  The only comment in the
maintenance log of the PROGnn member about DocuText was its addition to
the APF list in Sept. 2005, and that comment log dates back to when we
upgraded from z/OS 1.4 in Feb. 2004.

-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

Re: Monday blues? (IKJEFTSR RC=20,RSN=40)

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Brian Peterson
> 
> Did you ever check the ISPF TSO Command Table to see if 
> perhaps site modifications were accidentally regressed with 
> your z/OS maintenance?  

No; never even thought of it

> Perhaps you "used" to have an entry for DocuText in this 
> table, and now you don't. 

I'll review the Docu/Text install doc, but OTTOMH I don't recall
modifying anything ISPF-related except the ISPxLIB DD statements.

-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

Re: Monday blues? (IKJEFTSR RC=20,RSN=40)

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Mark Zelden
> 
> On Tue, 25 Jul 2006 09:38:29 -0500, Chase, John wrote:
> 
> >Since there seems to be a consensus here, I added the Docu/Text load 
> >library to //STEPLIB of the logon proc  Now it works again.
> >
> >**BUT**
> >
> >I checked archived copies of our logon proc dating back to the
original 
> >installation of Docu/Text here, and its load library has NEVER been
in 
> >the //STEPLIB concatenation; only in //ISPLLIB.  And the only thing 
> >that's changed since the Docu/Text installation is the maintenance 
> >level of z/OS 1.5 that we're running.
> >
> >Anyway, "problem solved" so thanks for all the ideas, etc.
> 
> Can we assume you don't have a sandbox that you can IPL with 
> the old level prior to maintenance and see if it is indeed 
> the maintenance that broke this?

Correct.  "Sandbox" gets the maintenance first, and its "alternate" RES
set has already been prepped for z/OS 1.7.

>  I really doubt that it did, but I hate mysteries.

Mysteries are fine, but everything that happens on a computer should be
explainable.  Unfortunately, I can't explain what I just went thru.

> Could this module have been in a local lnklst lib before and 
> perhaps someone did some cleanup?

I can't say definitively that that's not possible (that's as close as I
can come to saying, "No way, Jose").  The only comment in the
maintenance log of the PROGnn member about DocuText was its addition to
the APF list in Sept. 2005, and that comment log dates back to when we
upgraded from z/OS 1.4 in Feb. 2004.

-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

Re: Monday blues? (IKJEFTSR RC=20,RSN=40)

[Brian Peterson]

Did you ever check the ISPF TSO Command Table to see if perhaps site 
modifications were accidentally regressed with your z/OS maintenance?  
Perhaps you "used" to have an entry for DocuText in this table, and now you 
don't.  From ISPF Planning and Customizing:

3.17  Customizing the ISPF TSO command table (ISPTCM)

The ISPF TSO command table (ISPTCM) describes the TSO commands that are 
invoked under ISPF. When a TSO command is issued, ISPF searches ISPTCM. If 
the command is found, it uses the information in the table to process the 
command.  If the command is not in ISPTCM, ISPF uses default values, which 
are in the table.

Brian

On Tue, 25 Jul 2006 09:38:29 -0500, Chase, John wrote:

>Since there seems to be a consensus here, I added the Docu/Text load
>library to //STEPLIB of the logon proc  Now it works again.
>
>**BUT**
>
>I checked archived copies of our logon proc dating back to the original
>installation of Docu/Text here, and its load library has NEVER been in
>the //STEPLIB concatenation; only in //ISPLLIB.  And the only thing
>that's changed since the Docu/Text installation is the maintenance level
>of z/OS 1.5 that we're running.
>
>Anyway, "problem solved" so thanks for all the ideas, etc.
>
>-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

Re: Monday blues? (IKJEFTSR RC=20,RSN=40)

[Mark Zelden]

On Tue, 25 Jul 2006 09:38:29 -0500, Chase, John <[EMAIL PROTECTED]> wrote:

>Since there seems to be a consensus here, I added the Docu/Text load
>library to //STEPLIB of the logon proc  Now it works again.
>
>**BUT**
>
>I checked archived copies of our logon proc dating back to the original
>installation of Docu/Text here, and its load library has NEVER been in
>the //STEPLIB concatenation; only in //ISPLLIB.  And the only thing
>that's changed since the Docu/Text installation is the maintenance level
>of z/OS 1.5 that we're running.
>
>Anyway, "problem solved" so thanks for all the ideas, etc.
>

Can we assume you don't have a sandbox that you can IPL with the old
level prior to maintenance and see if it is indeed the maintenance
that broke this?  I really doubt that it did, but I hate mysteries.
Could this module have been in a local lnklst lib before and perhaps
someone did some cleanup?

Regards,

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group
mailto: [EMAIL PROTECTED]
z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

--
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

Re: Monday blues? (IKJEFTSR RC=20,RSN=40)

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Rob Scott
> 
> John,
> 
> I do not believe that IKJEFTSR looks in ISPLLIB for a load 
> module - IKJEFTSR is a TSO service - not ISPF.
> 
> If the only copy of D00YAAI is in an ISPLLIB dataset, then 
> IKJEFTSR is not lying to you - it cannot find the load module 
> using the normal module search order.

Since there seems to be a consensus here, I added the Docu/Text load
library to //STEPLIB of the logon proc  Now it works again.

**BUT**

I checked archived copies of our logon proc dating back to the original
installation of Docu/Text here, and its load library has NEVER been in
the //STEPLIB concatenation; only in //ISPLLIB.  And the only thing
that's changed since the Docu/Text installation is the maintenance level
of z/OS 1.5 that we're running.

Anyway, "problem solved" so thanks for all the ideas, etc.

-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

Re: Monday blues? (IKJEFTSR RC=20,RSN=40)

[Rob Scott]

John,

I do not believe that IKJEFTSR looks in ISPLLIB for a load module -
IKJEFTSR is a TSO service - not ISPF.

If the only copy of D00YAAI is in an ISPLLIB dataset, then IKJEFTSR is
not lying to you - it cannot find the load module using the normal
module search order.

Linklist or STEPLIB are the normal places for AUTHTSF modules - TSOLIB
will probably work as well.  


Rob Scott
Rocket Software, Inc
275 Grove Street
Newton, MA 02466
617-614-2305
[EMAIL PROTECTED]
http://www.rs.com/portfolio/mxi/
 

--
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

Re: Monday blues? (IKJEFTSR RC=20,RSN=40)

[Walt Farrell]

On 7/24/2006 4:27 PM, Craddock, Chris wrote:

However, program D00YAAI exists, lives in a library that is both
APF-authorized and concatenated in the //ISPLLIB concatenation, and
has AC=1.  I can browse the load module, so I know it's there.


Editorial comment, "it should not be AC=1". It just needs to be in an
authorized library. The presence of ANY unauthorized library in a given
concatenation renders that entire concatenation unauthorized. I would
look there first.


It would need AC(1) in order for IKJEFTSR to invoke it APF-authorized.

Or do you base your editorial comment on knowing what D00YAAI does, and 
thus some knowledge that it should not, in fact, run authorized when 
invoked directly?


Walt Farrell, CISSP
z/OS Security Design, IBM

--
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

Re: Monday blues? (IKJEFTSR RC=20,RSN=40)

[Walt Farrell]

On 7/25/2006 8:12 AM, Chase, John wrote:

There are unauthorized libraries in the //ISPLLIB concatenation.  But if
it's an authorization issue, why does the reason code translate to
"program not found" (reason code 40 (x'28')) instead of something like
"program not authorized"  (reason code 56 (x'38'))?


First, do you have D00YAAI listed in the AUTHTSF section of 
SYS1.PARMLIB(IKJTSOxx)?  If not, IKJEFTSR will run it (if found) but 
will simply run it unauthorized.


Next, as others have mentioned, IKJEFTSR will not find it in ISPLLIB. 
Actually, it may find it there, but only if you set the flags to 
indicate that you want to invoke the module in an un-isolated 
environment (i.e., not in the parallel TMP (isolated environment) where 
you would run authorized code).


In an isolated environment you are not running under ISPF, and thus "not 
found" would be the right return code.


If this worked before, then I believe you were (before) running it 
un-isolated, or you were finding it via a STEPLIB or TSOLIB rather than 
ISPLLIB.


Walt Farrell, CISSP
z/OS Security Design, IBM

--
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

Re: Monday blues? (IKJEFTSR RC=20,RSN=40)

[John P Kalinich]

On July 25, 2006, -jc- wrote:

>The Docu/Text load library is APF-authorized
>but not linklisted, and not in the LPA.  It *IS* in a concatenation
>(//ISPLLIB) that contains unauthorized libraries.

What happens if you TSOLIB the Docu/Text load library?

Regards,
John Kalinich
Computer Sciences Corp

--
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

Re: Monday blues? (IKJEFTSR RC=20,RSN=40)

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Andy Wood
> 
> On Mon, 24 Jul 2006 16:32:45 -0700, Edward Jaffe wrote:
> 
> >Doesn't ISPF attach it's tasks using ISPLLIB as a TASKLIB?
> 
> I think it does. However the message implied that D00YAAI was 
> an authorized program and as such it would be invoked by the 
> parallel TMP which would not have ISPLLIB in its TASKLIB. I 
> don't know what D00YAAI is, but 10 years ago I encountered a 
> similarly named Jobscan module, J00YAAI which had to be 
> listed in AUTHTSF.

D00YAAI is a Docu/Text module (same vendor as Jobscan), and is present
in both the AUTHPGM and AUTHTSR segments of IKJTSO00.  (But again, if it
were an authorization problem, why reason code 40 (program not found)
instead of 56 (program not authorized)?)

> If as stated there is no STEPLIB then I can only guess that 
> the module used to be located via linklist or in lpa, and 
> something changed in that regard.

No changes in that regard.  The Docu/Text load library is APF-authorized
but not linklisted, and not in the LPA.  It *IS* in a concatenation
(//ISPLLIB) that contains unauthorized libraries.

-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

Re: Monday blues? (IKJEFTSR RC=20,RSN=40)

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Jon Brock
> 
> Has this particular library perhaps taken an extent?  

No.

-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

Re: Monday blues? (IKJEFTSR RC=20,RSN=40)

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of David Day
> 
> Did you change anything in the way the program get's invoked. 
>  ISPEXEC SELECT  PGM vs. ISPEXEC SELECT CMD ??

Same failure both ways.

-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

Re: Monday blues? (IKJEFTSR RC=20,RSN=40)

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Craddock, Chris
> 
> > "This used to work."  
> 
> The usual question is "ok, if it was working before then what 
> changed?"

z/OS 1.5 preventive maintenance RSU0604, plus HIPERs and PEFIXes, were
applied.  Previous level was RSU0511.

> Do you see any other messages in the log?

None.

> > However, program D00YAAI exists, lives in a library that is both 
> > APF-authorized and concatenated in the //ISPLLIB concatenation, and
> has
> > AC=1.  I can browse the load module, so I know it's there.
> 
> Editorial comment, "it should not be AC=1".

Vendor supplies it with AC=1.

> It just needs to 
> be in an authorized library. The presence of ANY unauthorized 
> library in a given concatenation renders that entire 
> concatenation unauthorized. I would look there first.

There are unauthorized libraries in the //ISPLLIB concatenation.  But if
it's an authorization issue, why does the reason code translate to
"program not found" (reason code 40 (x'28')) instead of something like
"program not authorized"  (reason code 56 (x'38'))?

-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

Re: Monday blues? (IKJEFTSR RC=20,RSN=40)

[Andy Wood]

On Mon, 24 Jul 2006 16:32:45 -0700, Edward Jaffe 
<[EMAIL PROTECTED]> wrote:

>
>Doesn't ISPF attach it's tasks using ISPLLIB as a TASKLIB?

I think it does. However the message implied that D00YAAI was an 
authorized program and as such it would be invoked by the parallel TMP 
which would not have ISPLLIB in its TASKLIB. I don't know what D00YAAI is, 
but 10 years ago I encountered a similarly named Jobscan module, J00YAAI 
which had to be listed in AUTHTSF.

If as stated there is no STEPLIB then I can only guess that the module 
used to be located via linklist or in lpa, and something changed in that 
regard.

--
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

Re: Monday blues? (IKJEFTSR RC=20,RSN=40)

[Edward Jaffe]

Craddock, Chris wrote:

Why can't ISPF find it?



IKJEFTSR is TSO. I doubt that it knows or cares what is in ISPLLIB. It
probably does an ordinary LOAD - which is only going to look in the
standard contents supervisor search sequence unless the LOAD caller
(IKJEFTSR or a lower level function in this case) supplied a different
DCB.
  


Doesn't ISPF attach it's tasks using ISPLLIB as a TASKLIB?

--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/

--
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

Re: Monday blues? (IKJEFTSR RC=20,RSN=40)

[Ed Finnell]

 
In a message dated 7/24/2006 3:30:58 P.M. Central Standard Time,  
[EMAIL PROTECTED] writes:

Has this  particular library perhaps taken an extent?  



>>
There's VER command on PDS that will insure load mods are good to  go. Also a 
HIST that will tell when last  LKED. 

--
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

Re: Monday blues? (IKJEFTSR RC=20,RSN=40)

[Jon Brock]

Has this particular library perhaps taken an extent?  

Jon

--
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

Re: Monday blues? (IKJEFTSR RC=20,RSN=40)

[David Day]

Did you change anything in the way the program get's invoked.  ISPEXEC 
SELECT  PGM vs. ISPEXEC SELECT CMD ??
- Original Message - 
From: "Chase, John" <[EMAIL PROTECTED]>

Newsgroups: bit.listserv.ibm-main
To: 
Sent: Monday, July 24, 2006 2:51 PM
Subject: Re: Monday blues? (IKJEFTSR RC=20,RSN=40)



-Original Message-
From: IBM Mainframe Discussion List On Behalf Of McKown, John

Any chance that ISPLLIB (and maybe STEPLIB?) could contain an
non-APF authorized library? IIRC, that will remove the APF
authorization from all modules loaded via ISPLLIB regardless
of the AC value.


No //STEPLIB in the logon proc, and about half of //ISPLLIB is
unauthorized (and it's always been that way, AFAIK).

Besides, if it were an authorization problem I'd expect a different
diagnostic than "program not found".  Of course, this is TSO and
ISPF

   -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 


--
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

Re: Monday blues? (IKJEFTSR RC=20,RSN=40)

[Craddock, Chris]

> "This used to work."  Now I get:
<<>>
> The requested function (program, command, CLIST or REXX
> exec) was not found.

The usual question is "ok, if it was working before then what changed?"
Do you see any other messages in the log?

> However, program D00YAAI exists, lives in a library that is both
> APF-authorized and concatenated in the //ISPLLIB concatenation, and
has
> AC=1.  I can browse the load module, so I know it's there.

Editorial comment, "it should not be AC=1". It just needs to be in an
authorized library. The presence of ANY unauthorized library in a given
concatenation renders that entire concatenation unauthorized. I would
look there first.

> Why can't ISPF find it?

IKJEFTSR is TSO. I doubt that it knows or cares what is in ISPLLIB. It
probably does an ordinary LOAD - which is only going to look in the
standard contents supervisor search sequence unless the LOAD caller
(IKJEFTSR or a lower level function in this case) supplied a different
DCB.

CC

--
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

Re: Monday blues? (IKJEFTSR RC=20,RSN=40)

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of McKown, John
> 
> Any chance that ISPLLIB (and maybe STEPLIB?) could contain an 
> non-APF authorized library? IIRC, that will remove the APF 
> authorization from all modules loaded via ISPLLIB regardless 
> of the AC value.

No //STEPLIB in the logon proc, and about half of //ISPLLIB is
unauthorized (and it's always been that way, AFAIK).

Besides, if it were an authorization problem I'd expect a different
diagnostic than "program not found".  Of course, this is TSO and
ISPF

-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

Re: Monday blues? (IKJEFTSR RC=20,RSN=40)

[McKown, John]

Any chance that ISPLLIB (and maybe STEPLIB?) could contain an non-APF
authorized library? IIRC, that will remove the APF authorization from
all modules loaded via ISPLLIB regardless of the AC value.

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its
content is protected by law.  If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited. 

--
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

Monday blues? (IKJEFTSR RC=20,RSN=40)

[Chase, John]

Hi, All,

"This used to work."  Now I get:

ISPG071  
 
IKJEFTSR interface error 
Authorized program 'D00YAAI'. Return code = 20. Reason code = 40.

According to TFM, the RC=20 (decimal) means:

The IKJEFTSR parameter list contains an error. The fifth 
parameter contains the reason code associated with the 
error.

... and the RSN=40 (decimal) means:

The requested function (program, command, CLIST or REXX 
exec) was not found.

However, program D00YAAI exists, lives in a library that is both
APF-authorized and concatenated in the //ISPLLIB concatenation, and has
AC=1.  I can browse the load module, so I know it's there.

Why can't ISPF find it?

TIA,

-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