IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

Reading the abend Dumps


IBM Mainframe Forums -> CICS
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
rockish

Active User


Joined: 05 Jun 2009
Posts: 185
Location: Planet Earth

PostPosted: Wed May 15, 2013 4:12 am
Reply with quote

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
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Wed May 15, 2013 4:29 am
Reply with quote

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
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA

PostPosted: Wed May 15, 2013 4:49 am
Reply with quote

Click below and search for CEEPLPKA -

www-03.ibm.com/systems/resources/servers_eserver_zseries_zos_le_conference_pdf_swa8208.pdf
Back to top
View user's profile Send private message
rockish

Active User


Joined: 05 Jun 2009
Posts: 185
Location: Planet Earth

PostPosted: Wed May 15, 2013 5:08 am
Reply with quote

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
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Wed May 15, 2013 5:44 am
Reply with quote

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
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> CICS

 


Similar Topics
Topic Forum Replies
No new posts ISAM and abend S03B JCL & VSAM 9
No new posts Reading dataset in Python - New Line ... All Other Mainframe Topics 22
No new posts Find the size of a PS file before rea... COBOL Programming 13
No new posts Abend S0C4 11 (Page Translation Excep... PL/I & Assembler 16
No new posts WER999A - UNSUCCESSFUL SORT 8ED U Ab... SYNCSORT 5
Search our Forums:

Back to Top