View previous topic :: View next topic
|
Author |
Message |
rohanthengal
Active User
Joined: 19 Mar 2009 Posts: 206 Location: Globe, India
|
|
|
|
Here is a scenario:
I have written a COBOL- CICS program that reads a file stored at our Mainframe end for a certain customer and number of products requested for him/her.
So, i am dynamicall populating response based upon the number of products requested for that perticular customer.
When i execute this transaction in our Mainframes - CICS region, i am not getting any sort of Storage Violation. one notable thing, i found was i did not do FREEMAIN before RETURNing the transaction.
But when i ask other Teams who is the desired recipient (Java Area) to execute the same transaction through Java interface there is causing Storage Violation reports in Mainframe side CICS region job spool area.
Even, they are getting the proper response for whatever they requested us but not sure on why Storage Violation is occured when response is returned to them after the request/transaction executed by them...
Can anyone please help ? Will FREEMAIN help me to resolve this type of issue ? I am unable to test this due to some environment issue at my shop.. so started analysing the possibilities causing this issue.. |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
FREEMAIN may -- or may not -- help your problem. Your first issue is that you need to find out which CICS statement is being executed (or was last executed) when the storage violation occurred. This can be done by using CEDF, or using whatever CICS debugger (if any) is installed at your site, or (least desirable option) by adding debug statements to your code to use DISPLAY / WRITEQ TD to display the program flow and key variable values.
The problem sounds like it could be related to differences in the CICS regions (examples include SIT parameters, TWA size, or transaction / program definition differences), in which case the FREEMAIN issue could be completely irrelevant. Or the problem could be your program grabbing multiple chunks of memory in which case the FREEMAIN could resolve the problem. Without more understanding of the cause, you cannot say either way. |
|
Back to top |
|
|
rohanthengal
Active User
Joined: 19 Mar 2009 Posts: 206 Location: Globe, India
|
|
|
|
Thanks Robert..
I will definitely try FREEMAIN and lets see if the reason is same..
Everything works fine till i am working in CICS Mainframe region but as soon as i send response to Java region it starts giving me Storage Violation issue !!
Let me try different debuggings, i found the EXEC CICS command which was causing this Storage Violation to happen ... the command is EXEC CICS SEND response to Java request through same conversation id and populated COMMAREA with the dynamically calculated length |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
Quote: |
the command is EXEC CICS SEND response to Java request through same conversation id and populated COMMAREA with the dynamically calculated length |
You may want to get your site CICS support group involved to ensure that a system dump is generated for the first instance of the error; that dump can be run through IPCS and it could be used to find where the storage violation is occurring. I would suspect the "dynamically calculated length" since it may well NOT be dynamic at all. For example, if your variable is in WORKING-STORAGE in your COBOL program and you use LENGTH OF in your code, even if you use OCCURS DEPENDING ON the length will be generated by COBOL as the maximum possible length of the variable, no matter what the OCCURS DEPENDING ON indicates. |
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
In the dump, you should find a TRACE, which may help you in determining which storage-area SAA (most likely, the bottom) has been compromised. Unless STGRECVY (Storage Recovery) is active in the SIT (default is not active), when one or both SAA's have been compromised, an SV will occur. SAA's are also known as "Storage Check Zones".
By allowing the task to default and CICS to issue the FREEMAIN at task termination, the SV could have occurred much earlier in the flow.
Introducing an explicit FREEMAIN may give you the ability to locate the culprit.
However, keep in mind that COBOL Working-Storage is implicitly freed at LE enclave termination as well as task termination (last program in the task).
So, if WS "SAA(s)" have been corrupted, then this is another consideration.
Webcast replay: Debugging Storage Violations in CICS -
www-01.ibm.com/support/docview.wss?uid=swg27007891 |
|
Back to top |
|
|
Terry Heinze
JCL Moderator
Joined: 14 Jul 2008 Posts: 1249 Location: Richfield, MN, USA
|
|
|
|
Another aspect of Storage Violations to consider is that a SV usually points to the victim, not the culprit. The contents of the compromised SAA can sometimes reveal an "eye catching" phrase. |
|
Back to top |
|
|
rohanthengal
Active User
Joined: 19 Mar 2009 Posts: 206 Location: Globe, India
|
|
|
|
All friends, Thanks a lot and i suspect one cause here..
My program was receiving an input from Java source through Linkage Section - VARIABLE and i was extracting only required part of it and used to overwrite the same VARIABLE for some validations. Now when i moved that LINKAGE SECTION variable to some temorary WORKING STORAGE variable, i have not yet seen any Storage Violations happening in CICS region job.
Will this be real cause of Storage Violation abend as i see Main/Dynamic memory of Linkage section is getting overwritten in between ? |
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
I suspect that a halfword-binary length precedes the actual variable-data. This is its purpose, to allow the program to extract the data that was passed, using reference modification (1:halfword-binary).
LINKAGE SECTION data addressability very much differs from WORKING-STORAGE. Always keep this difference in mind. |
|
Back to top |
|
|
rohanthengal
Active User
Joined: 19 Mar 2009 Posts: 206 Location: Globe, India
|
|
|
|
Thanks Bill... you are right !! |
|
Back to top |
|
|
colin777
New User
Joined: 06 Jun 2013 Posts: 19 Location: Singapore
|
|
|
|
This has been a great thread
My only addition is to say that at the beginning of each Storage Check Zone is an 8 byte field. The first Byte will tell you which DSA the storage was Getmained from (M,B,C,U) and the other 7 bytes are the task no, which points to who owns this piece of storage. These 8 bytes must match at the end of the getmained piece of storage. If not then a Storage Violation has occurred.
In normal circumstances (without the CSFE trap being used), there are only 2 instances where CICS is forced to check that the Storage Check Zones match for each piece of storage.
1) when the Programmer issues an explicit EXEC CICS FREEMAIN
2) at the end of the task when CICS 'cleans' up after the transaction completes.
If the Storage Violation is found at the end of the Transaction, then CICS will issue :
DFHSM0102 applid A storage violation (code x'0F0C') has been detected in module name
HTH
Colin777 |
|
Back to top |
|
|
|