And the other question is 

If I have a STEPLIB and a JOBLIB and the module I need is only in the
JOBLIB, would not the step with the STEPLIB looking for that module fail?

//JOBLIB DD DSN=MYLOAD.LIB,DISP=SHR          Module XYZ resides here
//S1   EXEC  PGM=XYZ
//STEPLIB DD DISP=SHR,DSN=APPL.LIB              Module XYZ does not exist in
this library


Would not S1 then abend with a S806 due to the JOBLIB being ignored?

My understanding has been that if you code a JOBLIB any module not found in
the STEPLIB would then search the JOBLIB and hopefully not fail.  This would
also allow for testing a new version without having to alter JCL by swapping
load libraries on JOBLIB and STEPLIB.  I could have the production version
of the module in JOBLIB and a testing version in the STEPLIB.  If it is bad,
I delete the version in STEPLIB and the job will find it in the JOBLIB.

That as soon as the module was found, then no more searching no matter where
it was found.

So if it is in the STEPLIB, then searching stops
If it is found in the JOBLIB then searching stops
If it is found in the JPA, then searching stops.

So perhaps the intent is not that the JOBLIB is ignored. But that searching
stops if the module is found in the STEPLIB



Lizette



> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:[email protected]] On
> Behalf Of John Gilmore
> Sent: Friday, December 20, 2013 7:34 AM
> To: [email protected]
> Subject: Re: APF authorization and JOBLIB DD card
> 
> The last time I looked at the text Lizette quotes was a long time ago, and
its current
> version contains the subtext
> 
> <begin extract from extract>
> The directory is located on DASD with the data set, and is updated
whenever the
> module is changed. The directory entry contains information about the
module and
> where it is located in storage.
> </end extract from extract>
> 
> which is at best misleading.  The data-set directory contains no
information about
> where in virtual or real storage any copy of a member may have been loaded
and
> no indicator that it is currently resident.  The phrase 'in storage'
should replaced by
> 'in the data set'.
> 
> John Gilmore, Ashland, MA 01721 - USA

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to