Can a program know its load library?

[chong_zhou]

Sorry guys, I know I asked many questions at here recently, but I cannot contribute any answers. I am having a hard time as a new comer of Mainframe. So thank you in advance.

My question is:

When a program is running in TSO foreground or in a batch job in background, is it possible for the program to know which load library it comes from? By load library, I mean the DSN of the PDS(/E) where the program is loaded. Suppose the program is written in HLASM.

Actually, as a C programmer, I know the 'argv[0]' provided by LE, but I found out that it only provides a useless member name for a batch job program. I would like to know how the program can get the data set name (if it is possible).

Thank you very much!

[Robert Sample]

And how is this information helpful to the program? There may be hundreds or thousands of load libraries on a system, so what does the program gain by knowing it came from A.B.C.D versus A.B.D.E ?

[chong_zhou]

And how is this information helpful to the program? There may be hundreds or thousands of load libraries on a system, so what does the program gain by knowing it came from A.B.C.D versus A.B.D.E ?

Hi Robert, perhaps I didn't clearly state my question, sorry.

Suppose we have the following job step:

Code: Select all

STEP1    EXEC PGM=MYPROG,PARM='...'
STEPLIB  DD   DSN=MYNAME.LINKLIB,DISP=SHR
...
 

So when MYPROG is executed, JES will load the program image from MYNAME.LINKLIB(MYPROG) and runs it, right? My question is that if it is possible for MYPROG to know the dataset name 'MYNAME.LINKLIB'?

Because MYPROG wants to create a temporary JCL to run another program which is in the same load library where MYPROG is in. When it creates the JCL, it needs to put a JOBLIB or at least a STEPLIB DD statement in it.

[enrico-sorichetti]

wiser to review the whole design

[steve-myers]

I doubt you'll like this, but the general answer is no; in part because a program is not always loaded from a library; for example, a program loaded and executed by the linking loader function of the Binder can be loaded from the object output of the Assembler. Obviously that's not a library!

However, you can deduce some things, and possibly recover the library.

Step 1. Use the CSVQUERY macro to recover the module name and other module attributes.

Step 2. Use the OUTPID data returned by CSVQUERY to determine the loading service. If it is PGMF (program fetch) you can continue.

Step 3. Use the BLDL macro specifying the module name returned by CSVQUERY. BLDL will tell you if the module came from JOBLIB/STEPLIB (at this point there is no practical difference) or the link list. With difficulty you can then determine the library. Notice that things can still be somewhat indeterminate. For example, consider this JCL.

Code: Select all

//A       EXEC PGM=IEWL
//SYSLMOD  DD  DSN=&&TEMP(GO),...
//B       EXEC PGM=*.A.SYSLMOD

GO is loaded by program fetch, but it is not from the link list or JOBLIB/STEPLIB.

Now I have never done this, so I have no idea if it will work and I'm not about to waste several hours writing and testing code for this. I have done the step 3 part, so I know that is possible. Good luck.

So when MYPROG is executed, JES will load the program image from MYNAME.LINKLIB(MYPROG) and runs it, right? My question is that if it is possible for MYPROG to know the dataset name 'MYNAME.LINKLIB'?

JES does not "run" a job. It tells the operating system to "run" a job. JES has nothing to do with the mechanics of how the job is run.

[chong_zhou]

wiser to review the whole design

Enrico, thank you for your quick reply. Since I am working on an 'ancient' product, I don't have any right to review/modify the design, though I believe you are right and the design isn't very good indeed. Anyway, I'll take your answer as a 'no way'.

[chong_zhou]

I doubt you'll like this, but the general answer is no; in part because a program is not always loaded from a library; for example, a program loaded and executed by the linking loader function of the Binder can be loaded from the object output of the Assembler. Obviously that's not a library!

However, you can deduce some things, and possibly recover the library.

Step 1. Use the CSVQUERY macro to recover the module name and other module attributes.

Step 2. Use the OUTPID data returned by CSVQUERY to determine the loading service. If it is PGMF (program fetch) you can continue.

Step 3. Use the BLDL macro specifying the module name returned by CSVQUERY. BLDL will tell you if the module came from JOBLIB/STEPLIB (at this point there is no practical difference) or the link list. With difficulty you can then determine the library. Notice that things can still be somewhat indeterminate. For example, consider this JCL.

Code: Select all

//A       EXEC PGM=IEWL
//SYSLMOD  DD  DSN=&&TEMP(GO),...
//B       EXEC PGM=*.A.SYSLMOD

GO is loaded by program fetch, but it is not from the link list or JOBLIB/STEPLIB.

Now I have never done this, so I have no idea if it will work and I'm not about to waste several hours writing and testing code for this. I have done the step 3 part, so I know that is possible. Good luck.

JES does not "run" a job. It tells the operating system to "run" a job. JES has nothing to do with the mechanics of how the job is run.

Thank you so much Steve!! I will check IBM's document for CSVQUERY, OUTPID, BLDL, and try them in my test program first to see if it works. Your answer would be very helpful!

BTW, according to the 'great' design of the product, it is sure that the program is loaded from a load library referenced by a STEPLIB statement.

[steve-myers]

I wrote the following program to try CSVQUERY.

Code: Select all

CHONG    CSECT
         USING *,12
         SAVE  (14,12)
         LR    12,15
         LA    15,SAVEAREA
         ST    13,4(,15)
         ST    15,8(,13)
         LR    13,15
         ST    12,ADDRESS
         CSVQUERY INADDR=ADDRESS,SEARCH=JPA,OUTPID=PID,OUTMJNM=MODNAME
         CVD   15,DWORK
         UNPK  RC,DWORK
         OI    RC+L'RC-1,X'F0'
         OPEN  (PRINT,OUTPUT)
         PUT   PRINT,MESSAGE
         CLOSE PRINT
         L     13,4(,13)
         RETURN (14,12),RC=(15)
SAVEAREA DC    9D'0'
DWORK    DC    D'0'
PRINT    DCB   DSORG=PS,MACRF=PM,DDNAME=SYSPRINT,RECFM=FA,LRECL=121,  ->
               BLKSIZE=121
ADDRESS  DC    F'0'
MESSAGE  DC    0CL121' ',C' MODNAME  = '''
MODNAME  DC    CL8' ',C''', PID = '''
PID      DC    CL4' ',C''', RC = '
RC       DC    C'NNN',CL(L'MESSAGE-(*-MESSAGE))' '
         END   CHONG

After I assembled it I ran it with this JCL.

Code: Select all

//A       EXEC PGM=IEWL,PARM='MAP'
//SYSPRINT DD  SYSOUT=*
//SYSLMOD  DD  DISP=(,PASS),UNIT=SYSDA,SPACE=(TRK,(1,1,1)),DSN=&G(G)
//SYSLIN   DD  DISP=SHR,DSN=&SYSUID..CHONG.OBJ
//B       EXEC PGM=*.A.SYSLMOD
//SYSPRINT DD  SYSOUT=*
//C       EXEC PGM=LOADER,PARM=MAP
//SYSLOUT  DD  SYSOUT=*
//SYSLIN   DD  DISP=SHR,DSN=*.A.SYSLIN
//SYSPRINT DD  SYSOUT=*

Step B produced this output.

Code: Select all

MODNAME  = 'G       ', PID = 'PGMF', RC = 000

Step C produced this.

Code: Select all

MODNAME  = '**GO    ', PID = 'AOSL', RC = 000

[steve-myers]

OK. Here's a freebie. The PDSxxx symbols refer to the data area derived from a BLDL macro, that has been checked to determine the directory data was derived from JOBLIB or STEPLIB.

The method locates the real DCB used for JOBLIB or STEPLIB. it uses data in the DCB to determine the real JOBLIB or STEPLIB DD name. It copies that DD name to an unopened DCB in the program and uses RDJFCB to retrieve the JFCBs for the JOBLIB or STEPLIB. Finally it locates the correct JFCB and copies the data set name to the message. The ARL/ARA method used in the program is documented - poorly, in my opinion - in DFSMS Advanced Services for your z/OS release.

Code: Select all

* DETERMINE THE DDNAME OF THE JOBLIB/STEPLIB
         USING PSA,0               ESTABLISH PSA ADDRESSABILITY
         L     2,PSATOLD           LOAD ADDRESS OF THE CURRENT TCB
         USING TCB,2               ESTABLISH TCB ADDRESSABILITY
         L     3,TCBJLB            LOAD ADDRESS OF THE JOBLIB DCB
         USING IHADCB,3            ESTABLISH DCB ADDRESSABILITY
         SR    4,4                 LOAD THE OFFSET OF THE TIOT DD
         ICM   4,B'0011',DCBTIOT    ENTRY IN THE TIOT
         A     4,TCBTIO            COMPUTE ADDRESS OF THE JOBLIB TIOT ->
                                    DD ENTRY
         USING TIOENTRY,4
         MVC   (DCBDDNAM-IHADCB)+JOBLIB,TIOEDDNM  COPY THE DDNAME TO  ->
                                                   MY DCB
         RDJFCB JOBLIB             GET THE JFCB
         L     4,ARLAREA           LOAD ADDRESS OF THE ARA
         USING ARA,4               ESTABLISH ARA ADDRESSABILITY
         SR    5,5                 LOAD THE CONCATENATION
         IC    5,PDS2CNCT
NEXTJFCB LTR   5,5                 TEST REMAINING CONCATENATION
         BZ    GOTJFCB             IF 0, WE HAVE THE JFCB
         AH    4,ARALEN            COMPUTE ADDRESS OF THE NEXT JFCB
         BCTR  5,0                 SUBTRACT 1 FROM CONCATENATION
         B     NEXTJFCB
*                             0----+----1----+-
GOTJFCB  MVC   OUTLINE,=CL121' MODULE FOUND IN '  PREPARE THE OUTPUT
         MVC   OUTLINE+17(L'JFCBDSNM),JFCBDSNM     LINE
         PUT   PRINT,OUTLINE       WRITE THE OUTPUT LINE
         L     4,ARLAREA           LOAD ADDRESS OF THE ARA
         SR    5,5
         SR    6,6
         ICM   5,B'0111',ARLRLEN   LOAD THE LENGTH OF THE ARA
         IC    6,ARLPOOL           LOAD THE SUBPOOL WHERE THE ARL IS  ->
                                    LOCATED
         FREEMAIN R,LV=(5),A=(4),SP=(6)  FREE THE ARA
         ...
JOBLIB   DCB   DSORG=PO,MACRF=R,EXLST=XLIST
XLIST    DC    0A(0),AL1(X'80'+X'13'),AL3(XARL)
XARL     IHAARL DSECT=NO
         ...
OUTLINE  DC    CL121' '
         ...
         IHAPDS ,
         IHAPSA ,
         IKJTCB ,
         DCBD  DSORG=QS,DEVD=DA
TIOT     DSECT
         IEFTIOT1 ,
         IHAARA
ARA      DSECT                     RETURN TO THE ARA DSECT
         ORG   ARAJFCB
         IEFJFCBN ,

The JFCB, in essence is defined over the ARAJFCB data area in the ARA.

The IHAARL macro defines an actual, fully formatted, ARL that will direct the RDJFCB macro to construct the ARA.

As written, this code is RMODE 24 and is not reenterable. It will require some additional effort, which I leave up to you, if it must be RMODE ANY.