View previous topic :: View next topic
|
Author |
Message |
pkmurali Warnings : 1 Active User
Joined: 15 Dec 2005 Posts: 271
|
|
|
|
Dear all,
Need one clarification regarding using program-id in cobol.
I wrote an program with program-id 'sample'. i kept the program in a PDS as member 'test'. while compiling the program the load module is created as 'test' (since i referred the program name as test in my SCL). Compilation is succesful.
If i need to CALL the program via another program i have to issue 'sample'. if so how it will be detected? will it give me SOC4 abend? Please clarify.
Thanks,
Murali. |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
You will need to INCLUDE the module TEST as part of the linkage editor (binder) step of the other program's compile and link. |
|
Back to top |
|
|
Ronald Burr
Active User
Joined: 22 Oct 2009 Posts: 293 Location: U.S.A.
|
|
|
|
For a DYNAMIC call, the NAME being called must be the member name given to the load module in the one of the executable libraries available at run-time.
For a STATIC call, the NAME being called must be the PROGRAM-ID or some other defined ENTRY ID contained WITHIN the program being called, and the Load ( or Object ) Library Member Name must be included in the link-edit/bind step.
So, in your case, a DYNAMIC call would CALL 'TEST', and the library containing 'TEST' must be included in the JCL in a STEPLIB or JOBLIB concatenation
But a STATIC call would CALL 'SAMPLE', and you would have to specify INCLUDE PDSname(TEST) in the linkage-editor/binder SYSIN stream, where PDSNAME is the DDNAME assigned in the JCL to the PDS library that contains member TEST. |
|
Back to top |
|
|
MBabu
Active User
Joined: 03 Aug 2008 Posts: 400 Location: Mumbai
|
|
|
|
To understand these answers, it would help to have an explanation of the way that programs are compiled and linked.
Programs get compiled into an object deck; an intermediate form that represents just one of possibly many programs that will form your final load module. So if you have PROGRAM-ID A then you will get an object deck that contains a reference to A and if you have PROGRAM-ID B then you will get an object deck that contains a reference to B. It does not matter what the name of the source members are. That never gets saved anywhere by the compiler or the linker (well it does for debugging, but ignore that).
The linker (binder) than takes the object decks and creates a load module. That load module can itself have any name. The load module has data associated with it that says what program is the main program. So if you link A and B into a load module called C and assign B as the entry point, the a call to load module C will bring C into storage (remember, C contains A and B) and start program B.
Many source control systems assume that the program id is the same as the member name. It makes automating the compile and link easier. In your case, it is even assuming that each load module is made from a single source (!) and so the load module name is the same as the original source member name. That is why you are seeing something called TEST being generated. In the real world, load modules often are made of many source programs compiled into many object files and linked into the same load module. Common programs can even be statically linked into multiple load modules. |
|
Back to top |
|
|
Terry Heinze
JCL Moderator
Joined: 14 Jul 2008 Posts: 1249 Location: Richfield, MN, USA
|
|
|
|
Was there a reason why you used different names for the PROGRAM-ID and SCL member name? |
|
Back to top |
|
|
Ronald Burr
Active User
Joined: 22 Oct 2009 Posts: 293 Location: U.S.A.
|
|
|
|
Once, a long, long time ago, someone was attempting to test a new COBOL program that invoked an internal SORT, and decided to name the program ( you guessed it ) SORT, and placed the executable into the shared global test library.
It came as no surprise that many, many programmers began getting wild and crazy error messages when they tried to run the SORT program in a jobstream that contained a JOBLIB pointing to the shared global test library. It took us a while to determine WHO did the deed.
Moral: Keep your program names ( both internal and external ) a) the same ( unless there is a really, really compelling reason not to ), and b) unique to your functional area, so as not to take a chance of stomping on someone else's testing efforts. |
|
Back to top |
|
|
Terry Heinze
JCL Moderator
Joined: 14 Jul 2008 Posts: 1249 Location: Richfield, MN, USA
|
|
|
|
That is precisely the reason I asked the question! |
|
Back to top |
|
|
|