Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

S0C4 - Cobol Internal Table in Linkage section

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> CICS
View previous topic :: :: View next topic  
Author Message
cvishu

Active User


Joined: 31 Jul 2007
Posts: 136
Location: india

PostPosted: Mon Aug 27, 2012 3:41 pm    Post subject: S0C4 - Cobol Internal Table in Linkage section
Reply with quote

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.
Back to top
View user's profile Send private message

Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7232

PostPosted: Mon Aug 27, 2012 4:03 pm    Post subject: Reply to: S0C4 - Cobol Internal Table in Linkage section
Reply with quote

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 :-)
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 7913
Location: Bellevue, IA

PostPosted: Mon Aug 27, 2012 4:43 pm    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
cvishu

Active User


Joined: 31 Jul 2007
Posts: 136
Location: india

PostPosted: Mon Aug 27, 2012 5:24 pm    Post subject:
Reply with quote

Bill thnks icon_smile.gif

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)
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 7913
Location: Bellevue, IA

PostPosted: Mon Aug 27, 2012 5:49 pm    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
cvishu

Active User


Joined: 31 Jul 2007
Posts: 136
Location: india

PostPosted: Mon Aug 27, 2012 6:58 pm    Post subject:
Reply with quote

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 icon_smile.gif)
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.
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 7913
Location: Bellevue, IA

PostPosted: Mon Aug 27, 2012 7:13 pm    Post subject:
Reply with quote

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

CICS Moderator


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

PostPosted: Mon Aug 27, 2012 8:12 pm    Post subject: Reply to: S0C4 - Cobol Internal Table in Linkage section
Reply with quote

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

Your SYSPROG should have specified parm MEMLIMIT (for 64-Bit Storage allocation) to a minimum of 3G in the CICS startup.
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


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

PostPosted: Mon Aug 27, 2012 8:18 pm    Post subject:
Reply with quote

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

Global Moderator


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

PostPosted: Tue Aug 28, 2012 1:17 am    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
dick scherrer

Site Director


Joined: 23 Nov 2006
Posts: 19270
Location: Inside the Matrix

PostPosted: Tue Aug 28, 2012 1:37 am    Post subject:
Reply with quote

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

CICS Moderator


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

PostPosted: Tue Aug 28, 2012 1:44 am    Post subject: Reply to: S0C4 - Cobol Internal Table in Linkage section
Reply with quote

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.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> CICS All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
This topic is locked: you cannot edit posts or make replies. RANDOM Function in COBOL swapnil781 COBOL Programming 2 Tue Nov 15, 2016 6:17 pm
No new posts Regarding COBOL Stored Procedure opti... selvamsrinivasan85 DB2 4 Fri Nov 04, 2016 8:57 pm
No new posts COBOL Version 6.1 Virendra Shambharkar COBOL Programming 5 Tue Nov 01, 2016 11:24 am
No new posts Cobol list of programs being called biswajit.dattagupta COBOL Programming 5 Tue Nov 01, 2016 2:10 am
No new posts Can sending 5 MB data between cobol p... Kevin Vaz CICS 12 Tue Oct 18, 2016 4:50 pm


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us