CICS programs - NODYNAM compiler options.

venktv · New User Joined: 29 Mar 2006 Posts: 59 Location: Montreal

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
DFHEIBLK, CA-COMMAREA,
Copybook1,
Copybook2,

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
Copybook4
copybook5

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.

Bill O'Boyle · Posted: Mon Jul 19, 2010 7:48 pm

CICS/COBOL programs MUST be compiled with NODYNAM.

When CALLING a CICS program, regardless of the language, the normal parmlist is - DFHEIBLK, DFHCOMMAREA, "WHATEVER".

When a CICS/COBOL program is compiled, USING DFHEIBLK DFHCOMMAREA is automatically suffixed to the PROCEDURE DIVISION statement.

You need to change your CALL statement, to include DFHCOMMAREA as the second parameter.

Bill

CICS Guy · Posted: Mon Jul 19, 2010 7:50 pm

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.

Use DYNAM to cause nonnested, separately compiled programs invoked through the CALL literal statement to be loaded for CALL, and deleted for CANCEL, dynamically at run time. (CALL identifier statements always result in a runtime load of the target program and are not affected by this option.)

CICS Guy · Posted: Mon Jul 19, 2010 7:51 pm

Bill O'Boyle · Posted: Mon Jul 19, 2010 7:56 pm

I was emphasizing this fact because sometimes, people can get bad information from other's (such as management types).

But yes, I didn't delve into his question....

Bill

dbzTHEdinosauer · Posted: Mon Jul 19, 2010 8:10 pm

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.

venktv · New User Joined: 29 Mar 2006 Posts: 59 Location: Montreal

Hi everybody,

Thanks very much for the valuable suggestions.

Regards
Venkat

Bill O'Boyle · Posted: Mon Jul 19, 2010 9:31 pm

dbzTHEdinosauer · Posted: Mon Jul 19, 2010 10:37 pm

point 3, thanks for the update.

point 2, believe me - we have written subsystems, cobol called from a cics module, that dynamically call cobol modules, sometimes upto 18 deep.

only thing about point 2, we have found that linkage structures should not exceed 4k. can have multiples, but we found 4k max per structure was best.

Robert Sample · Posted: Mon Jul 19, 2010 10:44 pm

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.