PGM-1 is main CICS programs calling another CICS program PGM-2
PGM-1 compiled with RENT,NODYNAM,LIB
statements in PGM-1
05 Var-1 PIC X(08) VALUE 'PGM-2'
CALL Var-1 USING BY REFERENCE
PGM-2 again calling another DB2 program PGM-3
PGM-2 compiled with RENT,NODYNAM,LIB
statements in PGM-2
05 Var-2 PIC X(08) VALUE 'PGM-3'
CALL Var-2 USING USING Copybook3
Now, we are making changes to PGM-2, i.e. changing a working storage constant.
These programs are compiled with NODYNAM option, however used variables in CALL statements, so do i need to recompile and linkedit PGM-1 and PGM-3 along with PGM-2 to make the changes effective, please advise, thanks in advance.
Joined: 18 Jul 2007 Posts: 2149 Location: At my coffee table
Since PGM-2 and PGM-3 are called 'dynamically' (despite the NODYNAM), no.
You can verify that by looking at the link map for PGM-1 and PGM-2 and find no static binding for PGM-2 and PGM-3 respectively.
Joined: 14 Jan 2008 Posts: 2504 Location: Atlanta, Georgia, USA
Three simple rules:
programs written with CICS API's should always be NODYNAM.
Programs written to be invoked from COBOL CALL's - which don't contain CICS API's - should be DYNAM.
you should not COBOL CALL a module that has CICS API's.
Bullet point one is correct.
Bullet point two may or may not work. I've never tried calling a DYNAM compiled program from CICS. It will probably work, providing the sub-program does not CALL another sub-program. If there is a subsequent CALL, then those results are unpredictable.
Bullet point three. It's perfectly OK to CALL CICS programs, providing that the first two parameters are DFHEIBLK and DFHCOMMAREA. They are parm-addresses 01 and 02 off the R1 parmlist.
A CICS sub-program can determine how it's been accessed by checking (as the first line of code in the program), the contents of EIBRSRCE. If it's equal to the sub-program name, then it was accessed via a LINK-API. Otherwise, it has been CALLED.
Joined: 06 Jun 2008 Posts: 8547 Location: Dubuque, Iowa, USA
Dick, I hear you there! Back when I worked for a software vendor, we had a limit of 1500 bytes being passed to a subroutine. After the design was changed to allow up to 9999 bytes and the system shipped to customers, we found a S0C4 occurred. The customer's program, which called ours, was passing less than 4K and using 1 4-byte address for that data. Our program now expected 9999 bytes and was using 3 4-byte addresses. This messed up the linkage conventions, to say the least, and caused the S0C4.