Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
Because it is a CICS program, you must account for addressability to DFHEIBLK and DFHCOMMAREA.
Try changing the CALL structure to -
Code:
CALL PGM-SUB USING DFHEIBLK, DFHCOMMAREA, I-PARM.
Also, if you need to know how "PGM-SUB" had been accessed, as the first line of code in the PROCEDURE DIVISION, move EIBRSRCE to a WS-field.
Then, check the if WS-field is equal to the "PGM-SUB" name. If this is true, then it was accessed via a LINK-API (which worked for you). Otherwise, it had been CALLED.
However, in a CALL, if I-PARM were to be treated as DFHCOMMAREA, you have a challenge.
So, you need to set a WS-POINTER to the ADDRESS of DFHCOMMAREA, then set the ADDRESS of DFHCOMMAREA to the ADDRESS of I-PARM.
Before returning to the Caller, set the ADDRESS of DFHCOMMAREA to WS-POINTER.
You don't have to do this when the program is accessed via a LINK-API.
Inasmuch as the manual says the following is unnecessary, when the sub-program is accessed via a "CALL", my preference is to issue a "GOBACK", instead of "EXEC CICS RETURN", as this was the requirement way back when (old habits die hard).
You now have a sub-program, which can be accessed via a CALL or LINK-API.
One other little tidbit; in a LINK-API, LE (Language Environment) creates a new "ENCLAVE" (logical CICS level) and WS is allocated and freed upon program entry and return to the LINKING program.
Keep in mind that in a CALL, WS is allocated but not freed until task termination. So, if the WS is quite large in a CALL access, you could run the risk (although unlikely) of going SOS on EUDSA (31-Bit User-Storage) or (more likely) going SOS on UDSA (24-Bit User-Storage). User-Storage always runs in Key 9.
There is this pgm A (Db2) which needs to utilize a common program, say SUB-PGM (Db2). Pgm A needs to be working in CICS & Batch. So, i put the content of the procedure division of A into a copybook A and wrote 2 wrapper pgms AO (CICS) & AB (Batch) which will COPY A under their procedure divisions.
Now A will need to call SUB-PGM from the copybook.
If i use "CALL PGM-SUB USING DFHEIBLK, DFHCOMMAREA, I-PARM." in A, it is working for AO. But it is giving compile error that DFHEIBLK is undefined in AB.
How do i overcome this problem? Could you please help?
Joined: 08 May 2006 Posts: 1193 Location: Dublin, Ireland
I think you need to ensure that the sub-program is statically linked with the calling programs (at least with the CICS program). If you use dynamic call, CICS will require the DFHEIBLK and DFHCOMMAREA.
This would, of course, mean that any change to the sub-program would require re-link of the CICS program in order for the change to take effect.
[quote="Garry Carroll"]I think you need to ensure that the sub-program is statically linked with the calling programs (at least with the CICS program). If you use dynamic call, CICS will require the DFHEIBLK and DFHCOMMAREA.
COBOL non-CICS modules that are invoked in batch and in the CICS environment: As far as I know, call from CICS modules should be a simple dynamic COBOL CALL, not any CICS transfer of control or a CICS CALL nor any static linking. I have never seen otherwise. I will try to call a B/O module statically - hopefully, I will learn some new things...
In the above sub-program, I'd recommend substituting R12 with R3. If the caller is (most than likely) LE compliant, R12 contains the address of the LE 'CAA' (Common Anchor Area) belonging to the Caller and you may need this address in the future if management decides to make the above sub-program LE compliant.
One you've determined the run-environment and if it's CICS, write a small CICS/COBOL sub-program which you would CALL. This sub-program would issue an EXEC CICS ADDRESS EIB API. Also, define a one-byte WS field (IE: WS-DUMMY), which you'd use in the CALL as placeholders -
CALL WS-EIB-SUB-PGM USING WS-DUMMY, WS-DUMMY, WS-EIB-PTR.
SET ADDRESS OF LS-DFHEIBLK TO WS-EIB-PTR.
Having said this, if your CICS/DB2 sub-program issues CICS API's and these API's are needed for the logic path, then you're out of luck. You'd have to write a Batch version of this sub-program.
