View previous topic :: View next topic
|
Author |
Message |
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. |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
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 |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8697 Location: Dubuque, Iowa, USA
|
|
|
|
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 |
|
|
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) |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8697 Location: Dubuque, Iowa, USA
|
|
|
|
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 |
|
|
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. |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8697 Location: Dubuque, Iowa, USA
|
|
|
|
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 |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
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. |
|
Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
|
|
|
|
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 |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
|
|
|
|
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 |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
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 |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
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 |
|
|
|