|
View previous topic :: View next topic
|
| Author |
Message |
rockish
Active User
Joined: 05 Jun 2009
Posts: 185
Location: Planet Earth
|
|
|
|
Hi all,
I am pretty new to CICS and I am trying to look into an ASRA abend that has occurred in one of our transactions. The Program Interruption Code for this abend is 10 (Segment-Translation Excpetion) and hence I understand that the abend could be because of the memory overlay. I am trying to find the command in the program in which this error has occured. I checked the dump in IFA (IBM Fault Analyzer) and observed assembler instructions. One way to back track would be cross verify the instructions in the compiler listing with assembler instructions. But the compiler listing provided with me do not have the assembler instructions in it. Please let me know if there is anything else that I can look in the dump to understand the command in which the abend occured. First few lines of the dump is provided below for your reference,
| Code: |
Load Module Name. . . . . . : CEE.SCEERUN(CEEPLPKA)
At Address. . . . . . . . : 1EA00000
Load Module Length. . . . : X'202430'
Machine Instruction . . . . : BF6F7130 ICM R6,15,304(R7)
At Address. . . . . . . . : 1EAABBC0 (Module CEEPLPKA offset X'ABBC0')
AMODE . . . . . . . . . . : 31
Failing Operand . . . . . : Third operand
First Operand (R6). . . . : 1CE6069E
Second Operand Value. . . : X'0F'
Third Operand Address . . : D3C5D630 (Storage invalid)
Third Operand Length. . . : 0
Instructions around point of failure:
Offset Hex Instruction
------ -------------- --------------------------------------------------------
-2C 05EF BALR R14,R15
-2A 4140 A261 LA R4,609(,R10)
-26 5040 32CC ST R4,716(,R3)
-22 5820 D08C L R2,140(,R13)
-1E 5850 9008 L R5,8(,R9)
-1A 5840 2018 L R4,24(,R2)
-16 9140 5000 TM 0(R5),64
-12 5880 4004 L R8,4(,R4)
-E 5870 8000 L R7,0(,R8)
-A 4770 B150 BC 7,336(,R11)
-6 1277 LTR R7,R7
-4 4780 B150 BC 8,336(,R11)
***** BF6F 7130 ICM R6,15,304(R7)
+4 4780 B17E BC 8,382(,R11)
+8 1799 XR R9,R9
+A 5090 32CC ST R9,716(,R3)
+E 5850 2024 L R5,36(,R2)
+12 9680 5028 OI 40(R5),128
+16 949F 5028 NI 40(R5),159
+1A 5830 201C L R3,28(,R2)
Program Status Word (PSW) . : 079D1000 9EAABBC0
General Purpose Registers:
R0: 00000000 (2048 bytes of storage addressable)
R1: 1D9D770C (476805364 bytes of storage addressable)
R2: 1D9D770C (476805364 bytes of storage addressable)
R3: 1DC20160 (474410656 bytes of storage addressable)
R4: 0014101C (6311908 bytes of storage addressable)
R5: 1DC20018 (474410984 bytes of storage addressable)
R6: 1CE6069E (Module DFHAPLI CSECT DFHAPLI1 + X'1FFE')
R7: D3C5D500 (Storage invalid)
R8: 1DC255E0 (474389024 bytes of storage addressable)
R9: 1DC20008 (474411000 bytes of storage addressable)
R10: 1EAACA77 (Module CEEPLPKA + X'ACA77')
R11: 9EAABA78 (Module CEEPLPKA + X'ABA78')
R12: 1DC20160 (474410656 bytes of storage addressable)
R13: 1DC20A70 (474408336 bytes of storage addressable)
R14: 9EAABB00 (Module CEEPLPKA + X'ABB00')
R15: 9EAABA78 (Module CEEPLPKA + X'ABA78')
|
[/code] |
|
| Back to top |
|
 |
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
Well, it's gone bang in a Language Environment routine.
If you look at the address for the third operand, X'D3C5D630' which is invalid, this includes what may well be three letters, LEO.
The LE routine won't be causing the problem, it is just on the receiving end, and yes, I'd say something has been overwritten.
You'll have to find out what CALLed it, and likely go a couple or more CALLs back to find something recognisable. If nothing is showing the "call chain" then then you'll have to do it yourself. Start with Register 13, there is likely a "save area" around there, from which you take the previous Register 13 which was saved, etc, until you get to a module whose name is an application program. Likely a program that is being changed, or involved in the testing of a change :-) |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
| Back to top |
|
|
rockish
Active User
Joined: 05 Jun 2009
Posts: 185
Location: Planet Earth
|
|
|
|
Thanks for your input Mr. Bill Woodger!
I did see a few call chain data in my dump. But they were all DFH calls and hence I could not resolve the application program call chain. I was able to find the program that was failing from of the TACB of the event in which ASRA had occured but I was not able to do anything further :-(
| Code: |
The following events are presented in chronological order.
Event Fail Module Program EP
# Type Point Name Name Name Event Location (*) Loaded From
-- ------------ ----- -------- -------- -------- ---------------------- ------------
1 Call DFHSIP DFHKETA n/a P+3AA SOCNCICS.PROD.SDFHAUTH
2 Call DFHSIP DFHDSKE n/a P+206 SOCNCICS.PROD.SDFHAUTH
3 Call DFHSIP DFHXMTA n/a P+1050 SOCNCICS.PROD.SDFHAUTH
4 Call DFHAPPG DFHAPPG n/a P+4EE SOCNCICS.PROD.SDFHLOAD
5 Link DFHMIRS DFHMIRS n/a P+127E SOCNCICS.PROD.SDFHLOAD
6 Abend ASRA ***** CEEPLPKA n/a n/a M+ABBC0 CEE.SCEERUN
7 Call DFHAPLI DFHAPLI1 n/a P+2FCE SOCNCICS.PROD.SDFHLOAD
8 Call CEECCICS n/a CEECCICS E+546 CEE.SCEERUN
9 Call CEEPLPKA n/a CEECREIN E+2CF4 CEE.SCEERUN
10 Abend 4092 CEECCICS n/a n/a M+2D06 CEE.SCEERUN
|
|
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
| Sometimes when things are overwritten, other things get lost. A "save area" may have been overwritten. Are your CICS technical support people involved? Do you know which "transaction" caused it? Can you find LEO followed by X'30' in the dump and see what is in front of LEO? |
|
| Back to top |
|
|
|
|
  |
All times are GMT + 6 Hours |
|
