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
 

 

Regarding storage violation - CICS

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

New User


Joined: 20 Nov 2006
Posts: 13

PostPosted: Tue Jun 26, 2007 5:42 pm    Post subject: Regarding storage violation - CICS
Reply with quote

Hi,
We have a call to CICS program from Batch program through EXCI Link command. We have defined the commarea of batch program similar to that of comm area of CICS program. Still we do get Storage violation as mentioned below.

+DFHSM0102 CICPRDA A storage violation (code X'030B') has been detected by module DFHSMGF.
+DFHME0116 CICPRDA 712
(Module:DFHMEME) CICS symptom string for message DFHSM0102 is
PIDS/5655M1500 LVLS/640 MS/DFHSM0102 RIDS/DFHSMGF PTFS/UK13057
PRCS/0000030B
+DFHDU0201 CICPRDA ABOUT TO TAKE SDUMP. DUMPCODE: SM0102 , DUMPID: 163/0003
IEA794I SVC DUMP HAS CAPTURED: 828
+DFHDU0202 CICPRDA SDUMPX COMPLETE. SDUMPX RETURN CODE X'00'
828 DUMPID=005 REQUESTED BY JOB (CICPRDA )
828 DUMP TITLE=CICS DUMP: SYSTEM=CICPRDA CODE=SM0102 ID=163/0003
828
+DFHSM0102 CICPRDA A storage violation (code X'0F0C') has been detected by module DFHSMAR.
+DFHME0116 CICPRDA 831
831 (Module:DFHMEME) CICS symptom string for message DFHSM0102 is
831 PIDS/5655M1500 LVLS/640 MS/DFHSM0102 RIDS/DFHSMAR PTFS/HCI6400
831 PRCS/00000F0C
+DFHDU0201 CICPRDA ABOUT TO TAKE SDUMP. DUMPCODE: SM0102 , DUMPID: 163/0004
IEA794I SVC DUMP HAS CAPTURED: 899
899 DUMPID=006 REQUESTED BY JOB (CICPRDA )
899 DUMP TITLE=CICS DUMP: SYSTEM=CICPRDA CODE=SM0102 ID=163/0004
+DFHDU0202 CICPRDA SDUMPX COMPLETE. SDUMPX RETURN CODE X'00'
899
+DFHSM0102 CICPRDA A storage violation (code X'030B') has been detected by module DFHSMGF.

Please advice.

Thanks in advance.

Best Regards,
Priya
Back to top
View user's profile Send private message

William Thompson

Global Moderator


Joined: 18 Nov 2006
Posts: 3158
Location: Tucson AZ

PostPosted: Tue Jun 26, 2007 5:56 pm    Post subject:
Reply with quote

Look at the dump,
find the violated storage,
try to identify who violated the storage,
fix the problem.....
If you can reproduce it with "a call to CICS program from Batch program through EXCI Link command", so much the better, remember, it may not be the commarea.......
Back to top
View user's profile Send private message
sangiah

New User


Joined: 10 Jun 2005
Posts: 62

PostPosted: Thu Jun 28, 2007 9:00 am    Post subject:
Reply with quote

Hi,

How you compiled the Calling Program , did you call the PREPROCESSOR?..

CMDPREP ====> DFHECP1$ COBOL3,APOST,DEBUG,NOOPT,NOSEQ,SP

COMPILE ====> IGYCRCTL -> NOADV,C,FSRT,APOST,RENT,LIB,S,X,MAP,OFF,OPT(FULL),SIZE(MAX),TRUNC(BIN),LANG(UE),AWO

LINK ====> IEWL -> AMODE=31,RMODE=ANY,RENT,CALL,LIST,XREF,MAP
Back to top
View user's profile Send private message
kpriya6

New User


Joined: 20 Nov 2006
Posts: 13

PostPosted: Thu Jun 28, 2007 12:37 pm    Post subject:
Reply with quote

Hi,
The problem is it works fine in development region. But the same version is giving storage violation in Production region. But in both regions storage protection is active. What could be the reason for this to occur in Production alone.

Please advice.

Thanks and Regards,
Priya
Back to top
View user's profile Send private message
dick scherrer

Site Director


Joined: 23 Nov 2006
Posts: 19270
Location: Inside the Matrix

PostPosted: Thu Jun 28, 2007 12:44 pm    Post subject:
Reply with quote

Hello,

You might talk with your CICS system programmers and ask what is different between the 2 CICS enviroments.
Back to top
View user's profile Send private message
TG Murphy

Active User


Joined: 23 Mar 2007
Posts: 149
Location: Ottawa Canada

PostPosted: Thu Jun 28, 2007 6:18 pm    Post subject:
Reply with quote

Google: " A storage violation (code X'030B') has been detected by module DFHSMGF."

Result is:


DFHSM0102 Storage violation (code X'030B') when using a COMMAREA

Technote (FAQ)

Problem
You receive message DFHSM0102 A storage violation (code X'030B') has been detected by module DFHSMGF. You are passing data between application programs by specifying a communication area (COMMAREA) on an EXEC CICS LINK, XCTL, or RETURN command.

Cause
The length of the COMMAREA in the receiving program is longer than the length of the COMMAREA being passed. The receiving program is overwriting data outside the area that has been passed. The program may also be attempting to read data outside the area.

Solution
Do the following as documented in the CICS Application Programming Guide under COMMAREA:

To avoid this happening, your program should check whether the length of any communication area that has been passed to it is as expected, by accessing the EIBCALEN field in the EIBof the task. If no communication area has been passed, the value of EIBCALEN is zero; otherwise, EIBCALEN always contains the value specified in the LENGTH option of a LINK, XCTL, or RETURN command, regardless of the size of the data area in the invoked program.

You should ensure that the value in EIBCALEN matches the value in the DSECT for your program, and make sure that your transaction is accessing data within that area.

You may also add an identifier to COMMAREA as an additional check on the data that is being passed. This identifier is sent with the sending transaction and is checked for by the receiving transaction.

Problem Details
The program issuing the LINK command determines the length of the COMMAREA. The GETMAIN done by CICS on behalf of the linked-to program is based on what was received with the command. The definition for the DSECT in the LINKAGE section of the linked-to program is not taken into consideration when the storage is acquired. Thus, when the linked-to program tries to initialize storage for what it believes to be the length of the COMMAREA a storage violation, overlay of trailing check zone, occurs when the length passed in the LINK command is less than the length of the DSECT in the target program. This also applies to programs doing XCTL or RETURN commands.


More idea....

Display the value in EIBCALEN upon entry to the program. Display LENGTH OF your commarea.

Check the "USE" count of your target CICS program to see if it increases everytime an attempt is made to call it.

You mention that the sending commarea and receiving commarea are "similar". They should be identical - the same copybook should be used by sender and receiver. Double check that.

Consider asking your systems programmer to auxtrace the CICS region.

Send us your results and good luck.
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 CICS Transaction Timeout Hooman24 CICS 2 Sun Apr 16, 2017 2:16 pm
No new posts Date and time format in CICS Chandru3183 CICS 2 Sat Mar 18, 2017 12:46 pm
No new posts Asynchronous CICS Processing Question moezbud CICS 1 Mon Mar 06, 2017 6:13 pm
No new posts CICS Question RE: Browse, Readnext an... moezbud CICS 7 Sun Mar 05, 2017 5:45 am
No new posts how to send just 10 rows in a CICS sc... Megha Gupta CICS 5 Thu Feb 23, 2017 6:57 pm


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