|
View previous topic :: View next topic
|
| Author |
Message |
shankarm
Active User
Joined: 17 May 2010
Posts: 175
Location: India
|
|
|
|
Hi,
Am getting (s0c4/ASRA)storage violation in my CICS online region. This is the first time am getting storage violation in 20 years in our online region. The error message shows which program caused this abend. But i don't know how to find the root cause for this. Please help.
Following is the error message in my region,
| Code: |
DFHSM0102 ACOSP A STORAGE VIOLATION (CODE X'030B') HAS BEEN DETECTED BY MODULE D
DFHME0116 ACOSP
(MODULE:DFHMEME) CICS SYMPTOM STRING FOR MESSAGE DFHSM0102 IS
PIDS/5697E9300 LVLS/630 MS/DFHSM0102 RIDS/DFHSMGF PTFS/UK13134
PRCS/0000030B
DFHSR0622 ACOSP AN ATTEMPT TO OVERWRITE THE ECDSA HAS CAUSED THE ABEND WHICH FOL
DFHSR0001 ACOSP AN ABEND (CODE 0C4/AKEA) HAS OCCURRED AT OFFSET X'FFFFFFFF' IN P
DFHME0116 ACOSP
(MODULE:DFHMEME) CICS SYMPTOM STRING FOR MESSAGE DFHSR0001 IS
PIDS/5697E9300 LVLS/630 MS/DFHSR0001 RIDS/DFHSRP PTFS/UK05570
AB/S00C4 AB/UAKEA RIDS/OSPP085 ADRS/FFFFFFFF
XPFC200E Abend Information
XPFC201E Tran=O395 Task= 92030 Code=ASRA Program=OSPP085 ReqID= Resource=
XPFC202E PSW 079D2000 8030E13C 00040004 00000000
XPFC995E AR/GR 00:00000000/00000000_172BCB58 01:00000000/00000000_17240C48
|
Please let me know if you need more details/info. |
|
| Back to top |
|
 |
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
| Back to top |
|
|
shankarm
Active User
Joined: 17 May 2010
Posts: 175
Location: India
|
|
|
|
Thanks for the help Bill. I have checked it.
It says "Storage zone check fail". Any idea when/why this happens? |
|
| Back to top |
|
|
valyk
Active User
Joined: 16 Apr 2008
Posts: 104
Location: South Carolina
|
|
|
|
The most common cause is shorting yourself in linkage.
Say you GETMAIN 500 bytes and you set the address to an 01 group that is defined as 510 bytes. Whenever you move data to the last 10 bytes, you are over writing storage that you do not have addressability.
In CICS, the system will add check zones before and after the area of storage. CICS uses the check zones to make sure that your data has not been corrupted. In your example, you went beyond your GETMAIN'ed area and overwrote the check zone.
You can also do this with tables. If you GETMAIN enough storage for 10 occurrences, but you write to the 11th occurrence, you just caused a storage violation. |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
In the above document, "Storage Check Zones" (SCZ's) are the eight-byte values which surround the dynamic storage. Sometimes known as "Rabbit Ears" SCZ's are the placeholders used by CICS when issuing FREEMAIN API's as they are generated via a GETMAIN.
Many times, the bottom SCZ is written over by the application. For example -
| Code: |
WORKING STORAGE SECTION.
01 WS-SUB PIC S9(08) COMP.
LINKAGE SECTION.
01 DFHCOMMAREA PIC X(256).
MOVE 257 TO WS-SUB.
MOVE SPACES TO DFHCOMMAREA (WS-SUB:8).
|
In this example, the program is attempting to move SPACES to DFHCOMMAREA, beginning at position 257 for a length of eight.
Because the bottom SCZ (in reality) can be found in positions 257-264, it gets wiped out and now the program has guaranteed a subsequent FREEMAIN issue.
The problem usually occurs at task termination, when an implicit FREEMAIN is issued. Although the top SCZ is present, the bottom SCZ is gone and an SV occurs.
There is a way to prevent this, by activating Storage Protection as a SIT option, but the overhead is quite high for a Production environment and is not recommended.
The best way is to determine the program which acquired the storage (either implicitly or explicitly) and follow the steps in the IBM presentation.
You will need a Trace of the failed transaction (from the dump) to find who acquired the storage.
SV's can be difficult to find, so good luck.
Bill |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
I erroneously said -
| Quote: |
There is a way to prevent this, by activating Storage Protection as a SIT option |
Actually, it's Storage Recovery.
Bill |
|
| Back to top |
|
|
shankarm
Active User
Joined: 17 May 2010
Posts: 175
Location: India
|
|
|
|
Thank you, Thanks a lot Bill & valyk. Thats really great.
Bill, I read the same info from the IBM manuals also and i asked our cics team if the region is initialized with storage recovery. They say our region is initialized with STGRCVY(YES) (Storage recovery option in SIT is ON). I am not sure how did we get SCZ (when storage recovery is on).
Any Idea about his?
I got the below info from our cics logs for you reference,
| Code: |
| A STORAGE VIOLATION (CODE X'030B') HAS BEEN DETECTED BY MODULE DFHSMGF. |
030B/DFHSMGF fro the cics trace says its an SCZ. |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
| Quote: |
| CICS tries to repair any storage violation that it detects. |
to try does not imply to succeed |
|
| Back to top |
|
|
shankarm
Active User
Joined: 17 May 2010
Posts: 175
Location: India
|
|
|
|
Thanks Enrico, Thanks everyone.
Then i believe my issue is resolved. |
|
| Back to top |
|
|
|
|
