View previous topic :: View next topic
|
Author |
Message |
rikdeb
New User
Joined: 19 Jan 2009 Posts: 63 Location: hyderabad
|
|
|
|
Hi,
We have a cics pgm in cobol 2, which is wrking fine.the same program has been converted to LE cobol. We are facing storage violations.
SMCK *EXC* - Zone_check_failed. Its moving blanks in the address.
Could you please tell me if the parameter INITIMG is compatible with LE version in GETMAIN function. We are using CICS TS2.2. |
|
Back to top |
|
|
Binop B
Active User
Joined: 18 Jun 2009 Posts: 407 Location: Nashville, TN
|
|
|
|
rikdeb wrote: |
Could you please tell me if the parameter INITIMG is compatible with LE version in GETMAIN function. We are using CICS TS2.2. |
As per the manual INITIMG is certainly available in CICS TS2.2. To my knowledge <fingers crossed> there is no dependency on what type of COBOL you are using... |
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
The INITIMG keyword of the GETMAIN API is valid in any version/release, regardless of the language (COBOL, PL/I, Assembler, etc), so it's a red herring.
What changes (if any) were made to make the program LE compliant?
Check this previous post regarding SV's -
ibmmainframes.com/viewtopic.php?p=306519&highlight=#306519
HTH.... |
|
Back to top |
|
|
rikdeb
New User
Joined: 19 Jan 2009 Posts: 63 Location: hyderabad
|
|
|
|
No code changes were done. Its the same code converted thru CCCA tool.
The SV's which i am getting are very irregular. Sometimes its throwing and sometimes not.From the abend aid, it was seen that my program is trying to move data into DHFEAI module (CICS internal module).
An observation regarding the address displyed in dump.
PSW
is within a USER31 storage area
is within a USER24 storage area
is within a USER31 storage area
is within module appl-progam
Are these 24/31 bit adressing mode creating the prblm?
I can see blanks are getting over writen and causing that SV in all scenerios.
Any suggestions will be of grt help!
Thanks.. |
|
Back to top |
|
|
Edwin Green
New User
Joined: 21 Apr 2013 Posts: 1 Location: usa
|
|
|
|
Did you move low values to working storage for the application. LE uses the storage paramater in LE parms to initialize working storage. CICS and LE have reduced the amount of storage it will initialize. It is not efficient to have CICS initialize WS. I believe they limit the value they initialize to 6K now.
If you can recreate the problem with trace active do this. Turn on the trap. CSFE debug,chkstsk=current has redundant paramaters but it works. Make sure trace is active. Recreate the problem.
You will get a dump and the trap will be turned off on the first storage violation. Use IPCS to format the dump for trace. Locate the last E1 trace entry before the storage check failed. The return address in that entry will point to an offset in your program before the violation occurred. locate the E1 trace entry for which the trap springs. This will isolate the problem to between 2 exec cics command expansions. If the task number does not change between the 2 you have identified the culprit and not a victim. If you are able to step forward from the good entry and see where a Load half word is executed resulting in a large value for a MVC I would suspect that you did not initialize ws. |
|
Back to top |
|
|
|