View previous topic :: View next topic
|
Author |
Message |
Saikat Sengupta
New User
Joined: 08 Dec 2009 Posts: 15 Location: Mumbai
|
|
|
|
Hi
I am getting an error in my CICS module and the CICS log states:
DFHSR0001 HICSXXYY An abend (code 0C7/AKEA) has occurred at offset X'FFFFFFFF' in program XXXYYY01.
(For some internal restrictions I cannot post the exact module name and appologies for the same)
I want to know:
1) What does the offset X'FFFFFFFF' represent? How to trace the offset, since in the compile list of XXXYYY01 this address is not traceable.
2) Does the 0C7/AKEA abend represent some data exception with packed decimal data elements and some link module related error or in this case it may be something else thats causing the error?
One more point its just not one instance, the CICS log is showing this particular error more than once in every hour. |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
The offset represents a fullword binary value of negative one. This indicates that CICS was not able to identify the location of the abend. From the CICS Information Center I got
Quote: |
If the offset appears as X'FFFFFFFF', CICS was unable to establish the location of the program check. If this is the case, use the PSW to obtain the next sequential instruction address. The PSW may be found in the following places:
The TACB for the abend
At the head of the formatted transaction dump
Within the kernel error data block traced by exception trace point IDs AP 0781 or AP 0783
Now note down the start and end addresses of the different program areas in the transaction dump. Is the next sequential instruction address from the PSW in any of the programs? If so, then that is the program in which the interrupt occurred. Use the procedure described in Locating the last command or statement to identify the last command executed.
If the address is outside all of the programs, one of two things is likely to have happened.
The program in which the program check occurred was running on your behalf (for example, VSAM or DL/I), but not under CICS control. This is usually caused by incorrect parameters being passed to the program, or parameters being passed in the wrong sequence. These are usually caught and flagged with an appropriate return code, but certain combinations can cause problems.
Your program might have taken a "wild" branch into some other piece of storage. If the address from the PSW ends in an odd number, this is probably the case, as valid instructions are always on an even address. The address could be within the CICS address space, or anywhere else in virtual storage.
Often, a wild branch is taken to address zero, because the register that should contain the branch address is set to zero. The PSW usually contains address X'00000004' after such a branch has occurred.
Check the register contents to see whether any of them contains the next sequential instruction address from the PSW, or something close to it. This might help you find out how you got to the wrong address.
If the PSW does point to an instruction in one of your programs, the next thing to consider is the type of program check that occurred. Otherwise, turn directly to Analyzing the problem further. |
You're going to need a dump and probably a trace to figure this one out -- if you don't know how to get these, contact your site support group and work with your CICS system programmer.
S0C7 abends are ALWAYS caused by invalid numeric data in numeric variables (in COBOL). However, since CICS cannot identify the location, it is also possible that you have a program overwriting storage that does not belong to the program and that is causing the S0C7 -- without further debugging, it is not possible to tell. |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
It seems, from google, that you would get X'FFFFFFFF' when the abend is occurring in a module CICS does not know about, for instance a dynamic call is suggested as a possibility.
So, what are you doing? Yours is Cobol? What does it do to transfer control away from your module without using CICS? |
|
Back to top |
|
|
Saikat Sengupta
New User
Joined: 08 Dec 2009 Posts: 15 Location: Mumbai
|
|
|
|
Thanks Robert, Thanks Bill for the information. I have asked the CICS system programmer for details about the PSW for this error.
I will share something that I found from my region:
Code: |
HICSXXYY An abend (code 0C7/AKEA) has occurred at offset X'FFFFFFFF' in program
HICSXXYY 258
HMEME) CICS symptom string for message DFHSR0001 is
9700 LVLS/660 MS/DFHSR0001 RIDS/DFHSRP PTFS/UK53808
B/UAKEA RIDS/XXXYYY01 ADRS/FFFFFFFF |
Though I don't know if this is of any help.
Code'd |
|
Back to top |
|
|
Pandora-Box
Global Moderator
Joined: 07 Sep 2006 Posts: 1592 Location: Andromeda Galaxy
|
|
|
|
If you could check the displays in the CICS program
I would suggest adding displays of paranames so you could atleast narrow down to the problematic statement |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10873 Location: italy
|
|
|
|
Quote: |
(For some internal restrictions I cannot post the exact module name and appologies for the same) |
if You have restrictions on providing essential data then You should not ask on a public forum.
are You sure that the module name is an <application> module and not a CICS module
I have seen cases where a CICS module was referenced as the <abending> one |
|
Back to top |
|
|
Saikat Sengupta
New User
Joined: 08 Dec 2009 Posts: 15 Location: Mumbai
|
|
|
|
Quote: |
are You sure that the module name is an <application> module and not a CICS module
|
The program name XXXYYY01 in:
Quote: |
DFHSR0001 HICSXXYY An abend (code 0C7/AKEA) has occurred at offset X'FFFFFFFF' in program XXXYYY01 |
is an application module in CICS.
Regarding the restriction I guess I have not provided only the name of the exact module but shared the other essential details that I obtained from the spool |
|
Back to top |
|
|
|