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
 

 

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

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

Active User


Joined: 19 Mar 2009
Posts: 176
Location: Pune, Maharashtra, India

PostPosted: Mon Aug 05, 2013 2:59 pm    Post subject: Storage Violation (code - X'0F0C') has been detected
Reply with quote

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

Robert Sample

Global Moderator


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

PostPosted: Mon Aug 05, 2013 6:51 pm    Post subject:
Reply with quote

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
View user's profile Send private message
rohanthengal

Active User


Joined: 19 Mar 2009
Posts: 176
Location: Pune, Maharashtra, India

PostPosted: Mon Aug 05, 2013 8:19 pm    Post subject: Reply to: Storage Violation (code - X'0F0C') has been detect
Reply with quote

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

Global Moderator


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

PostPosted: Mon Aug 05, 2013 8:42 pm    Post subject:
Reply with quote

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
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 05, 2013 9:29 pm    Post subject: Reply to: Storage Violation (code - X'0F0C') has been detect
Reply with quote

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 -

http://www-01.ibm.com/support/docview.wss?uid=swg27007891
Back to top
View user's profile Send private message
Terry Heinze

JCL Moderator


Joined: 14 Jul 2008
Posts: 1238
Location: Richfield, MN, USA

PostPosted: Tue Aug 06, 2013 6:07 am    Post subject:
Reply with quote

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
View user's profile Send private message
rohanthengal

Active User


Joined: 19 Mar 2009
Posts: 176
Location: Pune, Maharashtra, India

PostPosted: Tue Aug 06, 2013 2:24 pm    Post subject:
Reply with quote

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
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 06, 2013 7:12 pm    Post subject: Reply to: Storage Violation (code - X'0F0C') has been detect
Reply with quote

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
View user's profile Send private message
rohanthengal

Active User


Joined: 19 Mar 2009
Posts: 176
Location: Pune, Maharashtra, India

PostPosted: Tue Aug 06, 2013 8:38 pm    Post subject:
Reply with quote

Thanks Bill... you are right !!
Back to top
View user's profile Send private message
colin777

New User


Joined: 06 Jun 2013
Posts: 19
Location: Singapore

PostPosted: Mon Aug 12, 2013 11:09 am    Post subject:
Reply with quote

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
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
No new posts PL/I code tuning/Performance improvement Virendra Shambharkar PL/I & Assembler 4 Mon Dec 05, 2016 11:57 am
No new posts What is the code in CLIST to enable t... jackzhang75 CLIST & REXX 1 Fri Dec 02, 2016 3:02 am
No new posts IDEAL - Code Retrieval yugendran CA Products 0 Fri Nov 25, 2016 3:27 pm
This topic is locked: you cannot edit posts or make replies. Need to code a Rexx PGM sundaram.naveen CLIST & REXX 18 Thu Oct 06, 2016 6:45 pm
No new posts Need Help in understanding what is th... mainakdalal PL/I & Assembler 9 Mon Oct 03, 2016 8:03 pm


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