View previous topic :: View next topic
|
Author |
Message |
Amb
New User
Joined: 12 Mar 2010 Posts: 64 Location: India
|
|
|
|
I have two programs COBPGM1 and COBPGM2
COBPGM1 calls COBPGM2.
I need to compile and link-edit these to programs.
I am using below JCL for both COBPGM1 and COBPGM2:
Code: |
//U225241A JOB 'ACBACCT#',CLASS=A,TIME=(0,59),NOTIFY=&SYSUID
// SET MEM=COBPGM1
//COMPILE EXEC IGYWCL,PARM='DYNAM,LIB'
//COBOL.SYSIN DD DSN=U225241.MY.COB.PGM(&MEM),DISP=SHR
//COBOL.SYSLIB DD DSN=U225241.MY.COB.COPYBKS,DISP=SHR
//LKED.SYSLMOD DD DSN=U225241.MY.COB.LOAD(&MEM),DISP=SHR
//SYSPRINT DD SYSOUT=*
//
|
I am able to compile and Linkedit the programs COBPGM1 and COBPGM2 using DYNAM option in Parm
But when I try to compile and linkedit it using NODYNAM
For COBPGM2 it works but for COBPGM1 the above jcl is failing.
It is giving the following error:
"MEMBER COULD NOT BE INCLUDED FROM THE DESIGNATED CALL LIBRARY."
Please let me know if the above jcl can be used as for static compile of cobol programs as well. |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
1. Learn what "static" and "dynamic" mean for COBOL. If you knew this, you would know -- already -- that your JCL is not correct for compliling programs using static calls.
2. Once you have done so, change your JCL for COBPGM1 to include the approrpriate changes to resolve the error. The compile JCL for COBPGM2 will not need changing. Hint: you'll need to add 2 DD statements to the LKED step and issue some linkage editor / binder commands. |
|
Back to top |
|
|
Amb
New User
Joined: 12 Mar 2010 Posts: 64 Location: India
|
|
|
|
Sorry to bother you again.
I tried to understand the difference betwen Static and Dynamic compile. I also understood that my compile JCL is not able to find the load module for COBPGM2.
So I need to add another DD statement for LKED.SYSLMOD which will contain the load module for COBPGM2. Please correct me if I am wrong.
Also I was not able to understand what linkage/binder commands do I need to specify in my JCL? |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
You will need to tell the linkage editor / binder when compiling COBPGM1 to include the COBPGM2 program, will you not? |
|
Back to top |
|
|
Kjeld
Active User
Joined: 15 Dec 2009 Posts: 365 Location: Denmark
|
|
|
|
Does your installation not provide compile and link services for general use, either as template batch jobs, or as processor services in your source library system? |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello,
You should not create your own compile/link jcl. You should use the standard processes for the system you are working on.
Several of my clients make the use of the standard compile processes a condition of continued employment (use the standard processes or be terminated).
Suggest you talk with the people who support the compiler. . . |
|
Back to top |
|
|
Amb
New User
Joined: 12 Mar 2010 Posts: 64 Location: India
|
|
|
|
Yes we do have a standard process, but I want to know this out of curosity.
@Robert
I tried a lot and also tried to incorporate your suggestion. I also googled for the Linkage commands but am not able to run the above jcl.
Please give me the modification that I need to do in the above step so that the JCL runs. Thanks in advance. |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello,
If you are curious, use the standard jcl and study each and every jcl statement, compiler option, and linkage editor process. Everything you need to know is in the standard process(es).
If your system uses cics and/or db2, suggest you learn about how those processes work as well.
In any case, there is no reason to use non-standard jcl. Actually - it is a bit stronger than that. I have supported organizations that creating your own is reason for termination. They are simply not willing to let this happen. |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
If you have LKED.SYSLIB pointing to the load library containing COBPGM2, your linkage edit JCL should have
Code: |
//LKED.SYSLIB DD DSN=<WHATEVER>,DISP=SHR
//LKED.SYSIN DD *
INCLUDE SYSLIB(COBPGM2)
/* |
and there is a linkage editor / binder manual (I don't recall which bookshelf, exactly) that contains the various commands. |
|
Back to top |
|
|
Amb
New User
Joined: 12 Mar 2010 Posts: 64 Location: India
|
|
|
|
Thanks Robert |
|
Back to top |
|
|
don.leahy
Active Member
Joined: 06 Jul 2010 Posts: 765 Location: Whitby, ON, Canada
|
|
|
|
Sometimes standard compile processes are set up in such a way that it is very hard to learn anything. I work in an Endevor shop, and all you see in your JCL is a step that invokes the Endevor processor, which is pretty much a black box to most people. You have to dig deep to figure out what the processor is really doing. |
|
Back to top |
|
|
Kjeld
Active User
Joined: 15 Dec 2009 Posts: 365 Location: Denmark
|
|
|
|
don.leahy wrote: |
Sometimes standard compile processes are set up in such a way that it is very hard to learn anything. I work in an Endevor shop, and all you see in your JCL is a step that invokes the Endevor processor, which is pretty much a black box to most people. You have to dig deep to figure out what the processor is really doing. |
Along with a Endevor installation development support have to provide a description of the object types that Endevor will store, and what processing will be performed on the object.
One of the major challenges in compiler and linkage editor setup is to establish the library concatenation sequences for the different environments, and for that you will rely on information from internal resources. |
|
Back to top |
|
|
|