Can a program know its load library?



High Level Assembler(HLASM) for MVS & VM & VSE

Can a program know its load library?

Postby chong_zhou » Fri Dec 01, 2017 6:17 pm

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!
chong_zhou
 
Posts: 40
Joined: Wed Nov 01, 2017 8:59 pm
Has thanked: 21 times
Been thanked: 0 time

Re: Can a program know its load library?

Postby Robert Sample » Fri Dec 01, 2017 7:09 pm

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 ?
Robert Sample
Global moderator
 
Posts: 3719
Joined: Sat Dec 19, 2009 8:32 pm
Location: Dubuque, Iowa, USA
Has thanked: 1 time
Been thanked: 279 times

Re: Can a program know its load library?

Postby chong_zhou » Fri Dec 01, 2017 7:22 pm

Robert Sample wrote: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:


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.
chong_zhou
 
Posts: 40
Joined: Wed Nov 01, 2017 8:59 pm
Has thanked: 21 times
Been thanked: 0 time

Re: Can a program know its load library?

Postby enrico-sorichetti » Fri Dec 01, 2017 7:33 pm

wiser to review the whole design
cheers
enrico
When I tell somebody to RTFM or STFW I usually have the page open in another tab/window of my browser,
so that I am sure that the information requested can be reached with a very small effort
enrico-sorichetti
Global moderator
 
Posts: 2994
Joined: Fri Apr 18, 2008 11:25 pm
Has thanked: 0 time
Been thanked: 164 times

Re: Can a program know its load library?

Postby steve-myers » Fri Dec 01, 2017 7:38 pm

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

These users thanked the author steve-myers for the post:
chong_zhou (Fri Dec 01, 2017 7:52 pm)
steve-myers
Global moderator
 
Posts: 2105
Joined: Thu Jun 03, 2010 6:21 pm
Has thanked: 4 times
Been thanked: 243 times

Re: Can a program know its load library?

Postby chong_zhou » Fri Dec 01, 2017 7:42 pm

enrico-sorichetti wrote: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
 
Posts: 40
Joined: Wed Nov 01, 2017 8:59 pm
Has thanked: 21 times
Been thanked: 0 time

Re: Can a program know its load library?

Postby chong_zhou » Fri Dec 01, 2017 7:52 pm

steve-myers wrote: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.
//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.
chong_zhou
 
Posts: 40
Joined: Wed Nov 01, 2017 8:59 pm
Has thanked: 21 times
Been thanked: 0 time

Re: Can a program know its load library?

Postby steve-myers » Fri Dec 01, 2017 9:49 pm

I wrote the following program to try CSVQUERY.
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.
//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.
MODNAME  = 'G       ', PID = 'PGMF', RC = 000
Step C produced this.
MODNAME  = '**GO    ', PID = 'AOSL', RC = 000

These users thanked the author steve-myers for the post:
chong_zhou (Fri Dec 01, 2017 10:13 pm)
steve-myers
Global moderator
 
Posts: 2105
Joined: Thu Jun 03, 2010 6:21 pm
Has thanked: 4 times
Been thanked: 243 times

Re: Can a program know its load library?

Postby steve-myers » Sun Dec 03, 2017 9:05 pm

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.
* 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.
steve-myers
Global moderator
 
Posts: 2105
Joined: Thu Jun 03, 2010 6:21 pm
Has thanked: 4 times
Been thanked: 243 times


Return to Assembler

 


  • Related topics
    Replies
    Views
    Last post