S0C4 - Cobol Internal Table in Linkage section

cvishu · Active User Joined: 31 Jul 2007 Posts: 136 Location: india

Hi ,

I had a Cobol Internal Table in the working storage section of a Web service program. As it was resulting in huge Getmains , i tried to move the Cobol Internal Table to Linkage section , but now its issuing a S0C4 .

Is there anything specific i need to do if i declare an Cobol Internal Table in the linkage section.

PS . The same declaration in Linkage section works when i issue a Explicit Getmain.

PLease advice.

Bill Woodger · Posted: Mon Aug 27, 2012 4:03 pm

If you have a definition in the LINKAGE SECTION you need to explicitly attach it to an address. If you use the definition before doing this, you'll get a S0C4.

In your case, you need to get hold of some storage, and then give the mapping the address of the storage. Sounds like what you've done to get it to work, but without realising that that is the way that it works :-)

Robert Sample · Posted: Mon Aug 27, 2012 4:43 pm

Whether in LINKAGE SECTION or WORKING-STORAGE SECTION, the memory has to be allocated for your program to use. So merely moving data definitions from WORKING-STORAGE to LINKAGE will not have any major impact on your program.

cvishu · Active User Joined: 31 Jul 2007 Posts: 136 Location: india

Bill thnks

Robert - For CICS i read somewhere that when an Internal Cobol table , will occupy max storage when in WS section , but whe defined in LINKAGE Section will pick up memory dynamically ( through Getmains)

Robert Sample · Posted: Mon Aug 27, 2012 5:49 pm

For tables defined as OCCURS DEPENDING ON (ODO), what you say is somewhat (but not completely) true -- but ODO has not been mentioned yet in this thread, so the presumption is that ODO is not being used. If it is being used, that is a critical piece of data that should have been mentioned in the very first post. For tables not defined with ODO, the same amount of storage will be allocated in WORKING-STORAGE or LINKAGE SECTION.

However, the system is NOT "picking up memory dynamically" as you put it -- someone, in some program, has to determine how much storage is needed and issue the GETMAIN to get that storage. LINKAGE SECTION variables are NOT defined in the program using them, and hence there is no storage allocated for anything in LINKAGE SECTION when the program starts up -- unlike WORKING-STORAGE where storage allocation occurs when the program starts.

Even with ODO, the amount of savings will depend upon what is happening with the program. If the ODO specifies 0 TO 1000, for example, and the variable is set to 990 when the GETMAIN is done, there is total saving of 1% of the maximum possible storage allocation. It would take a LOT of executions for that kind of savings to be visible.

Furthermore, there is another point to consider. CICS is a transactional system -- it is designed to be used to do one thing, do it quickly, and then go on to the next thing. Allocating "huge Getmains" -- wherever they are being allocated -- almost certainly indicates someone is attempting to take a batch process and make it work in CICS. A transaction should not need huge amounts of memory since it should not be doing a whole lot of processing. Doing so could negatively impact response times for everyone using that CICS region.

cvishu · Active User Joined: 31 Jul 2007 Posts: 136 Location: india

Robert ,
Since i was just looking for the S0C4 issue , i didnt give full details which may have mislead you.

Corrections:
1) Yes i am refering to a Occurs Depending ON Clause.
2) Yes am having a program logic to get the count of eligible rows ( from database) and issue Getmain based on the count ( this is what i was referring to as dynamic allocation may be a wrong term

)
3) The problem with Getmains is each Task is issuing a getmain of 10 mb. and ther was a performance testing to simulate 40 simultaneous occurances and it exceeded 400 mb resulting in a SOS.

Hope i explained my scenario , if i am missing any details please feel free to ask.

Robert Sample · Posted: Mon Aug 27, 2012 7:13 pm

You are going is a VERY WRONG direction. The manual gives the default limit for EDSA in CICS as 34M -- so you were attempting to acquire more than 11 X the default memory for your one transactin. Personally, I am impressed with your CICS system programmer's restraint in not looking for you with baseball (or cricket) bat in hand!

No CICS transaction should be attempting to allocate 10 MB for anything; doing so indicates issues and (as you saw) produces system resource problems almost immediately.

Bill O'Boyle · Posted: Mon Aug 27, 2012 8:12 pm

If your CICS Version/Release is TS/3.2 or greater, review CHANNELS/CONTAINERS, which utilize 64-Bit storage (under the covers), rather than EUDSA.

TS/3.1 (when they were introduced), uses EUDSA.

Your SYSPROG should have specified parm MEMLIMIT (for 64-Bit Storage allocation) to a minimum of 3G in the CICS startup.

dbzTHEdinosauer · Posted: Mon Aug 27, 2012 8:18 pm

this is the same problem from your other thread.

the web service invokes your module.

the web service expects data returned.

is this data to be returned defined in another linkage area?

dbzTHEdinosauer · Posted: Tue Aug 28, 2012 1:17 am

cvishu,

I asked in the other thread and you provided no answer.

I suggest to you that your processing philosophy is not correct.

you insist on using more storage than is available.
you insist on using more storage than you need.

as long as you continue with your current design,
you are not going to have a satisfactory solution.

if you want help,
you must supply enough info so that we can help you improve your design.

if you do not want us to help you redesign this mess,
then don't.

it is after all, your problem, and you can keep it to yourself if you wish.

dick scherrer · Posted: Tue Aug 28, 2012 1:37 am

Hello,

It is (probably) time to bring in someone who has already done this multiple times to get a few samples running and teach the people who are just learning.

Things, in cases like yours, often go "live" because "something" worked - or seemed to have worked. The politics were such that delivering something that did not work and was not supportable was overlooked due to some percieved crisis.

Bill O'Boyle · Posted: Tue Aug 28, 2012 1:44 am

Your SYSPROG should define a unique tranclass for this transaction (maxactive=1), regardless of your version/release.

You would then have a method to attempt to control the storage allocated at any given time.

A transaction/program such as this should not be defined as OpenAPI/Threadsafe and should be defined as Concurrent.