I am writing a new COBOL / CICS webservice program and am calling a subprogram which does all DB2 retrievals.
I am currently using a LINK to call the subprogram, but the GETMAIN / FREEMAIN associated with each LINK is causing trailing SSA overlay and abending my transaction with 0C4 / AKEA.
1. Is there an option by which I can continue using LINK and avoid the SSA overlay?
2. If not, I am planning to convert the LINK to a CALL to avoid these issues. Since I am having multiple CICS programs in which this subprogram might be called,
2a. Is it better to have a separate module for the subprogram?
2b. Or, should I embed this subprogram as a separate program entry in each of the mainprogram source modules as given below. Does this give any performance advantages?
Thank you for the response, and thanks to BILL especially... A quick update...
I was checking this with the CICS admins from my mainframe shop alongside of reaching you all and got the info that the issues were in the statements where the LINK statement were being executed.
So, I tried issuing a CALL instead of a LINK and it solved the issue.
Garry, I am not sure how this solved the issue though, especially as the previous version of the same code (without explicit GETMAIN / FREEMAIN statements for other data areas inside the code worked without any issues).
My Link statement goes like this,
EXEC CICS LINK(PRG)
LENGTH(LENGTH OF AREA1)
DbZ, excuse me, I have issued only an EXIT program in the called module, this was a sample code that I cut pasted for reference and left in a TYPO...
Joined: 14 Jan 2008 Posts: 2504 Location: Atlanta, Georgia, USA
Just so you're aware, if "someone" decides to use MRO (Yikes!) and this sub-program now lives in a remote-region, you MUST access it via a LINK-API. The CALL access can only be used in the same/local region.
In a LINK-API, the commarea is copied (under the covers) so it can be used in the remote-region and re-copied back so that the LINKING region can check for commarea-changes, etc.
One other issue, don't pass or return pointers/addresses in the commarea, because they'll be invalid in the remote-region and local-region (if the address is from the remote-region) and you'll raise all sorts of "opportunities". IBM has never advocated the passing of pointers, plus you don't want some burly CICS System Programmer chasing you down the hallway, foaming at the mouth.
Also, DTR (Dynamic Transaction Routing) could bite you as well.
If the commarea-length exceeds 32763, then take a look at CHANNELS and CONTAINERS. Many think the max is 32767, but it's actually 32763.