View previous topic :: View next topic
|
Author |
Message |
sivakumar.karthik
New User
Joined: 21 Apr 2005 Posts: 4 Location: chennai
|
|
|
|
Hi,
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?
Id division.
Program-id. Outer-program.
Procedure division.
Call "Inner-1".
Stop run.
Id division.
Program-id. Inner-1
...
Call Inner-1a.
Stop run.
Id division.
Program-id. Inner-1a.
...
End Inner-1a.
End Inner-1.
End Outer-program. |
|
Back to top |
|
|
Garry Carroll
Senior Member
Joined: 08 May 2006 Posts: 1193 Location: Dublin, Ireland
|
|
|
|
Neither a GETMAIN nor FREEMAIN will cause a trailing SAA overlay since neither actually moves data.
Quote: |
1. Is there an option by which I can continue using LINK and avoid the SSA overlay?
|
Yes - determine where, in YOUR code, YOU are overlaying the trailing SAA and correct it.
It's probable that your overlay will continue to cause you problems even if you use CALL rather than LINK.
Garry. |
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
Besides the trailing SAA being overwritten after issuing an explicit GETMAIN, a trailing SAA of GETMAIN storage, implicitly allocated by LE (such as program WS), could also be getting corrupted.
I would suggest contacting your CICS System Programmer and have he/she use the IPCS facility to locate the overlay.
This might help - "Anatomy of a CICS Storage Violation" -
www-01.ibm.com/support/docview.wss?uid=swg27020205&aid=1
HTH.... |
|
Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
|
|
|
|
I see that you are using a STOP RUN
instead of EXIT PROGRAM in a CICS module.
not very good.
should use EXIT PROGRAM in any COBOL module,
whether it be Batch or CICS. |
|
Back to top |
|
|
sivakumar.karthik
New User
Joined: 21 Apr 2005 Posts: 4 Location: chennai
|
|
|
|
Hi Garry / Bill / DbZ,
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)
COMMAREA(AREA1)
LENGTH(LENGTH OF AREA1)
END EXEC
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... |
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 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.
HTH.... |
|
Back to top |
|
|
|