Storage Violation (code - X'0F0C') has been detected

rohanthengal · Posted: Mon Aug 05, 2013 2:59 pm

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

Robert Sample · Posted: Mon Aug 05, 2013 6:51 pm

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.

rohanthengal · Posted: Mon Aug 05, 2013 8:19 pm

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

Robert Sample · Posted: Mon Aug 05, 2013 8:42 pm

Bill O'Boyle · Posted: Mon Aug 05, 2013 9:29 pm

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

Terry Heinze · Posted: Tue Aug 06, 2013 6:07 am

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.

rohanthengal · Posted: Tue Aug 06, 2013 2:24 pm

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 ?

Bill O'Boyle · Posted: Tue Aug 06, 2013 7:12 pm

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.

rohanthengal · Posted: Tue Aug 06, 2013 8:38 pm

Thanks Bill... you are right !!

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