Portal | Manuals | References | Downloads | Info | Programs | JCLs | Mainframe wiki | Quick Ref
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist 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 FUSE - IBM MQ - CICS integration error Kevin Vaz CICS 1 Mon Sep 18, 2017 4:31 pm
No new posts Julian Date to CICS ABSTTIME blayek CICS 3 Wed Aug 30, 2017 11:15 pm
No new posts Need to track the CICS transaction fr... sam8051 CICS 3 Mon Aug 07, 2017 3:11 pm
No new posts Iterative use of a REXX script causin... bryonyh CLIST & REXX 4 Fri Jul 28, 2017 12:52 pm
No new posts How to Clear all TSQs during CICS sta... Hooman24 CICS 10 Mon Jun 26, 2017 9:46 pm

Facebook
Back to Top
 
Job Vacancies | Forum Rules | Bookmarks | Subscriptions | FAQ | Polls | Contact Us