IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

Embedded programs / link'ed programs


IBM Mainframe Forums -> CICS
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
sivakumar.karthik

New User


Joined: 21 Apr 2005
Posts: 4
Location: chennai

PostPosted: Fri Jun 05, 2015 1:12 am
Reply with quote

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
View user's profile Send private message
Garry Carroll

Senior Member


Joined: 08 May 2006
Posts: 1193
Location: Dublin, Ireland

PostPosted: Fri Jun 05, 2015 1:46 pm
Reply with quote

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
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA

PostPosted: Fri Jun 05, 2015 4:42 pm
Reply with quote

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
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Mon Jun 08, 2015 5:54 pm
Reply with quote

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
View user's profile Send private message
sivakumar.karthik

New User


Joined: 21 Apr 2005
Posts: 4
Location: chennai

PostPosted: Mon Jun 08, 2015 9:06 pm
Reply with quote

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). icon_question.gif

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
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA

PostPosted: Mon Jun 08, 2015 9:40 pm
Reply with quote

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. icon_eek.gif

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
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> CICS

 


Similar Topics
Topic Forum Replies
No new posts Fetch data from programs execute (dat... DB2 3
No new posts Passing Parameters to Programs Invoke... PL/I & Assembler 5
No new posts Finding Assembler programs PL/I & Assembler 5
No new posts How can i link the RHDCSNON programa ... IDMS/ADSO 2
No new posts Recompiling programs after a copybook... COBOL Programming 1
Search our Forums:

Back to Top