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

issues with memory in programs with containers/getmain logic


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: Thu Aug 13, 2015 8:56 pm
Reply with quote

Hi all,

I have a set of cics programs,

PGMA gets input xml data from an MQ (until End of Queue).

PGMA LINKS PGMB to put it into DB2 tables.

PGMA LINKS PGMC to retrieve data from DB2 tables and move it to data containers (set of group data items) and then transform them to XML using TRANSFORM DATATOXML command.


The data containers (as expected) are HUGE, since there are multiple iterations of data possible. The structures are linked somewhat like this.

01 GROUP1.
05 VAR1 PIC X(10).
...
05 GRP2-NUM PIC S9(4) COMP.
...
01 GROUP2.
05 GROUP2-OCRS OCCURS 1 TO 99 TIMES DEPENDING ON GRP2-NUM.
...
...
01 GROUP100.
...

Since the possible occurrences are only one or two for most groups, it does not make sense to have hold all the extra space.

So, I wrote GETMAIN / FREEMAIN Logic, by moving max occurrence value for each structure and then freeing it up as soon as the processing for the structure is over. While freeing the main memory, GRP2-NUM does not have the same value as 99, since, I change it during program processing and would have max value of 1 or 2.

My problem lies thus, memory is being eaten up by PGMC. I have put in debug statements and find that the number of getmains match the number of freeemains and that if any message errors out, I make sure I freeup the memory before throwing an exception.

This might not be a big problem, if not for my underlined statement at the top, (ie) for each input message one instance of PGMC is being called. This builds up memory consumption, ultimately exceeding the total EUDSA available, and bringing down the region.

I have researched and exhausted all options available, know that it is not a perfect design as the memory eatup might also be due to using a large number of get container / put container commands too. But the design cannot be altered now.

Any suggestions please?
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA

PostPosted: Thu Aug 13, 2015 11:48 pm
Reply with quote

Are you telling us that you GETMAIN for 99 occurrences but your FREEMAIN only does 2 occurrences? If so, the answer to your problem is QUITE obvious -- FIX THE BROKEN PROCESS! If you allocate 99 bytes of memory through GETMAIN, you need to free 99 bytes of memory with FREEMAIN -- period. If this is not what your issue is, then you need to explain in more detail just why PGMC keeps using more memory.

Have you discussed your problem with your site support group? If not, that should have been (and remains) your FIRST contact. If so, have you followed their advice? If not, do what they tell you. If you did and still have a problem, you need to go back to them and work closer with them to resolve your issue. They can do things (such as increasing CICS region size) that we on this forum cannot -- although increasing CICS region size is not always a recommended approach since the amount of memory on a system is limited.
Back to top
View user's profile Send private message
sivakumar.karthik

New User


Joined: 21 Apr 2005
Posts: 4
Location: chennai

PostPosted: Thu Aug 13, 2015 11:55 pm
Reply with quote

Robert, The GETMAIN / FREEMAIN is on the 01 level item, so, I assumed that even if my number of occurrences change, it should not matter since it is always on a lower level. Would it matter?

I did not go to my site's support group, since I wanted to clean up my house and see if it was a logic issue or if the cause was my program before going back to them.

Thanks for your response.
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA

PostPosted: Fri Aug 14, 2015 12:07 am
Reply with quote

The answer is that it can matter, depending upon how you coded your program. If the LENGTH in the FREEMAIN isn't freeing the entire area allocated by the GETMAIN, that could explain the issue right there. Have you run through CEDF (or whatever tool your site has available) to see the lengths of the GETMAINs and the lengths of the FREEMAINs?

Many issues are brought to this forum which should have been addressed by the site support group. The site support group knows the site much better than anyone on a forum could, and they generally have access to tools (such as traces, dumps, software products) that make it easy to diagnose problems such as memory issues.
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 Aug 14, 2015 4:39 pm
Reply with quote

Regarding the GETMAIN's, I must assume you're acquiring 31-Bit storage using the FLENGTH keyword, specifying a binary-fullword? Acquiring 24-Bit storage (keyword LENGTH) should not even be a consideration.

If a task is not at termination and you're leaving a given program to go to another (IE: XCTL or RETURN to the Linking program) it's always good practice to issue an explicit (programmatic) FREEMAIN of GETMAIN storage previously acquired. Otherwise, this allocated storage remains dormant/orphaned until task termination, when CICS issues an implicit FREEMAIN.

Are you experiencing SOS SV dumps? This happens when a dispatched task is requesting CICS for 'X' amount of contiguous storage, but it's not available and could cause the region to completely stop, unless the EUDSA limit is dynamically increased.

In the region startup, what value is defined in the SIT for the EDSA limit (DSA storage above 16MB)? You may want to speak to your System Programmer about a possible increase.

When using Channels and Containers (introduced with CICS/TS 3.1) in a CICS/TS 3.2 and greater environment, the contents are kept above the bar (64-Bit storage). However, when a given program needs access, the contents are transferred to 31-Bit storage. So, if these Channels and Containers are using large amounts of storage, you could take a hit.

Unfortunately, COBOL's AMODE (currently) can't be any greater than 31. PL/I, C and Assembler can have AMODE 64, but I'm unsure what type of effect this would have on the Channel and Container storage for one of these AMODE 64 programs.

The following PDF may be helpful -

www.redbooks.ibm.com/redbooks/pdfs/sg247227.pdf

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 Issues with VIEW DATASET Command CLIST & REXX 2
No new posts Finding Assembler programs PL/I & Assembler 5
No new posts Finding faulty logic Subscript out of... COBOL Programming 5
Search our Forums:

Back to Top