IBM Mainframe Forum

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!

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



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.

wiser to review the whole design

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

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

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.

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.

I wrote the following program to try CSVQUERY.After I assembled it I ran it with this JCL.Step B produced this output.Step C produced this.

These users thanked the author steve-myers for the post:

chong_zhou (Fri Dec 01, 2017 10:13 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.
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.