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

How to determine where is error in abend code ?


IBM Mainframe Forums -> PL/I & Assembler
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
jackzhang75

Active User


Joined: 09 Jun 2014
Posts: 124
Location: CT

PostPosted: Fri Apr 15, 2016 2:01 am
Reply with quote

Hi Experts,

I got the assambler code and RC=0 after compiling but ABEND S0C4 when run this program. So anyone can give the the clue or procedure how to find where exactly the error in the code from following information?

IEA705I ERROR DURING FREEMAIN SYS CODE = 978-04 TU14 AAAMVS AAAMVS 00
IEA705I 00FA3D00 00870E88 00870E88 00000300 00008000 000D6156
IEA995I SYMPTOM DUMP OUTPUT
SYSTEM COMPLETION CODE=978 REASON CODE=00000004
TIME=16.30.11 SEQ=04003 CPU=4000 ASID=00F3
PSW AT TIME OF ERROR 070C1000 815DD358 ILC 2 INTC 0D
NO ACTIVE MODULE FOUND
NAME=UNKNOWN
DATA AT PSW 015DD352 - 00181610 0A0D18CE 18FB180C
AR/GR 0: 00000000/84000000 1: 00000000/84978000
2: 00000000/000D6A0C 3: 00000000/00000003
4: 00000000/00870E88 5: 00000000/00870E00
6: 00000000/815D8310 7: 00000000/00FA3D00
8: 00000000/00000000 9: 00000000/00007FFA
A: 00000000/800D6156 B: 00000000/7F481430
C: 00000000/00004000 D: 00000000/000D6008
E: 00000000/000D1CA4 F: 00000C05/00000004
END OF SYMPTOM DUMP
Abend 978000 hex occurred processing command 'XPCP '.
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8574
Location: Dubuque, Iowa, USA

PostPosted: Fri Apr 15, 2016 2:33 am
Reply with quote

The 978-04 means a STORAGE or FREEMAIN was passed an address that does not start on a double-word boundary. The XPCP at the end of your posted data indicates you are using Xpediter for debugging. So either you messed up a STORAGE or FREEMAIN invocation, or there is a storage overlay occurring in your code that affected the executing code. If it is a storage overlay, you have to find the culprit in your code. In this case, most of the dump information you posted will be unhelpful at best, misleading at worst.
Back to top
View user's profile Send private message
steve-myers

Active Member


Joined: 30 Nov 2013
Posts: 886
Location: The Universe

PostPosted: Fri Apr 15, 2016 4:49 am
Reply with quote

There is a pattern in the ABEND codes, though it's gotten somewhat messed up. Let's look at your 978-04

78 - That's a hexadecimal representation of an SVC number, 120 in this case. SVC 120 is what I think of as the "native" MVS GETMAIN and FREEMAIN macros, to differentiate it from SVCs 4, 5 and 10, the OS/360 macros. OS/360 GETMAIN and FREEMAIN were very strange, which is why there were 3 SVCs. I think I can write about that, but it's irrelevant to this topic.

9 is just a code, essentially meaningless any more, that IBM can use to look at the code in the SVC 120 module to - maybe - get an idea where in the code something went wrong. Well, at least find the ABEND macro. At least give IBM researchers a good clue as to where they should look in the mess of control blocks used for storage management. For most ABENDs, this code is sort of useful. Long ago 213 effectively meant one thing: a data set it was trying to open is not on the disk volume where it was supposed to be. 13 (19) is OPEN. OPEN TYPE=J is a different SVC, but all it's ABENDs are x13.

04 - is "reason" code, from the ABEND macro. For some ABENDs it is helpful; for x78 ABENDs it's basically meaningless.

Now, going back to your 978. Mr. Sample talked about STORAGE and FREEMAIN. STORAGE is basically the "native" MVS GETMAIN/FREEMAIN, but wrapped around a PC instruction rather than an SVC instruction. Ultimately it uses the SVC 120 code, which means the x78 ABENDs.

HTH
Back to top
View user's profile Send private message
steve-myers

Active Member


Joined: 30 Nov 2013
Posts: 886
Location: The Universe

PostPosted: Fri Apr 15, 2016 5:26 am
Reply with quote

I'll repeat discussion about the symptom dump in the topic starter's post. Sadly, it's basically useless here, but -

SYSTEM COMPLETION CODE=978 REASON CODE=00000004

We've pretty much discussed this already.

PSW AT TIME OF ERROR 070C1000 815DD358 ILC 2 INTC 0D
NO ACTIVE MODULE FOUND

PSW (Program Status Word) is a 64-bit (well, now a translation of the actual 128 bit register) that tells us where we are and other information. 815DD358 is the current instruction address and the current AMODE. The AMODE is the very first bit - 8 indicates AM0DE 31. 15DD358 is the instruction address. ILC is an Instruction Length Code - useful for 0C4 ABENDs, but otherwise not very valuable. NO ACTIVE MODULE FOUND means summary dump was unable to locate the module where the ABEND macro was located, which for many ABENDs is meaningless.

DATA AT PSW 015DD352 - 00181610 0A0D18CE 18FB180C

Much of the time this is the most useful part of the summary dump. 0A0D is the ABEND SVC instruction. Here it's just about useless. At a guess, 0018 is the last 2 bytes of a LA instruction. 1610 is an OR instruction. 18CE, 18FB and 180C are LR instructions, but since they follow the 0A0D instruction they are not really part of the instruction stream.

HTH
Back to top
View user's profile Send private message
steve-myers

Active Member


Joined: 30 Nov 2013
Posts: 886
Location: The Universe

PostPosted: Fri Apr 15, 2016 6:13 am
Reply with quote

Let's look at a more useful symptom dump -
Code:
IEA995I SYMPTOM DUMP OUTPUT
SYSTEM COMPLETION CODE=0C4  REASON CODE=00000004
 TIME=19.09.53  SEQ=02740  CPU=0000  ASID=0026
 PSW AT TIME OF ERROR  078D0000   91700FEA  ILC 4  INTC 04
   ACTIVE LOAD MODULE           ADDRESS=11700FD0  OFFSET=0000001A
   NAME=MAKE0C4
   DATA AT PSW  11700FE4 - C02850C0  B00098EC  D00C9601
   GR 0: FD000008   1: 00006FF8
      2: 00000040   3: 009D09D4
      4: 009D09B0   5: 009FD098
      6: 009C0FE0   7: FD000000
      8: 009F91C8   9: 009CF9C8
      A: 00000000   B: 01000000
      C: 91700FD0   D: 00006F60
      E: 80FD6C08   F: 91700FD0
 END OF SYMPTOM DUMP
PSW AT TIME OF ERROR 078D0000 91700FEA ILC 4 INTC 04

91700FEA is the AMODE (31) and the instruction address (11700FEA).

DATA AT PSW 11700FE4 - C02850C0 B00098EC D00C9601

We know from the ILC that the failing instruction is 4 bytes, so we can see it is 50C0 B000, or ST 12,0(,11). We can see in the registers that register 11 is 01000000, which is probably bad. The interrupt code (INTC) is 4, which indicates a storage key issue rather than a virtual address translation issue. It also confirms the failing instruction is the ST instruction, not the next instruction, 98EC D00C (LM 14,12,12(13)). If the INTC was 10 or 11, the failing instruction would be the LM instruction. As it happens, we have the listing of the failing module, a luxury the analyst seldom has -
Code:
000012 58B0 C028            00028    12          L     11,=A(X'1000000')
000016 50C0 B000            00000    13          ST    12,0(,11)
                                     14          RETURN (14,12),T,RC=0
00001A 98EC D00C            0000C    16+         LM    14,12,12(13)
and it confirms the analysis of the summary dump. I grant this is pretty artificial, but that's what the analyst does.

HTH
Back to top
View user's profile Send private message
Abid Hasan

New User


Joined: 25 Mar 2013
Posts: 88
Location: India

PostPosted: Fri Apr 15, 2016 5:00 pm
Reply with quote

Thank you Steve, the post was informative.
I remember reading an old but excellent post on the forum by Mr. Brenholtz on the lines of dump reading, a fair while back; but I somehow am unable to locate it currently.
Aside, it'd be kind of you if you can share some essential reading material with regards to dump analysis (other than the POP manual) for a novice.

Thank you.
Back to top
View user's profile Send private message
Willy Jensen

Active User


Joined: 01 Sep 2015
Posts: 472
Location: Denmark

PostPosted: Fri Apr 15, 2016 5:36 pm
Reply with quote

Look in Messages & Codes for IEA705I . As I recall it contains an explanation for the fields in the 2nd line of IEA705I. If not, the System Codes for S978 should tell you that.
Back to top
View user's profile Send private message
steve-myers

Active Member


Joined: 30 Nov 2013
Posts: 886
Location: The Universe

PostPosted: Fri Apr 15, 2016 7:21 pm
Reply with quote

Mr. Jensen is correct. However, <personal experience on> the few times I've tried to interpret this data using the description in the Messages manual, I've gotten nowhere, so I don't bother any more <personal experience off>. If you're lucky, for something like an 80A or 878, you can deduce the amount of storage requested and the subpool.


Abid Hasan: Sadly, I don't know of one - at lesst one that has been published. There are so many ABENDs, and such a wide variety of possible tools and techniques, it's not really possible to to do something here. I deleted all my prep workup for the MAKE0C4 analysus, though it would be easy to reproduce it.
Back to top
View user's profile Send private message
Abid Hasan

New User


Joined: 25 Mar 2013
Posts: 88
Location: India

PostPosted: Fri Apr 15, 2016 9:30 pm
Reply with quote

Thank you Steve, Mr. Jenson; indeed the I%%%%%I/E/W and other messages yield ample information for analysis if interpreted and understood correctly.
I was referring to reading dumps in general, abends and otherwise. From what I have understood over the time, one needs to have a good understanding of 'the good stuff' from 'Principles of Operation' - just to begin with; once we understand that, then there is tons of other stuff for example MVS data areas etc. For a beginner in dump reading, one can easily get lost looking at the mounds of information and not knowing the right path to follow.

My apologies for hijacking the original topic, though.

Thank you.
Back to top
View user's profile Send private message
steve-myers

Active Member


Joined: 30 Nov 2013
Posts: 886
Location: The Universe

PostPosted: Fri Apr 15, 2016 10:02 pm
Reply with quote

Abid Hasan wrote:
... I was referring to reading dumps in general, abends and otherwise. From what I have understood over the time, one needs to have a good understanding of 'the good stuff' from 'Principles of Operation' - just to begin with; once we understand that, then there is tons of other stuff for example MVS data areas etc. For a beginner in dump reading, one can easily get lost looking at the mounds of information and not knowing the right path to follow.
Actually, one rarely needs the POP for dump analysis. You do need a rough knowledge of MVS control blocks and how they connect together. As you say, it's awfully easy to get lost in the forest of control blocks
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8574
Location: Dubuque, Iowa, USA

PostPosted: Sat Apr 16, 2016 1:09 am
Reply with quote

Quote:
when i use jcl to run the program why i get different abned information ?
Because Xpediter changes the way code works.

Did you notice in the non-Xpediter abend that your registers are not right? And did you notice that registers 0 through 2 have <blank><blank>JOB51971 in them? And did you notice that running the program under CICS will give you exactly the same results since you don't do anything to prevent the program from running under CICS?

There's enough oddness in your code that it's no surprise that you got the S0C4.
Back to top
View user's profile Send private message
jackzhang75

Active User


Joined: 09 Jun 2014
Posts: 124
Location: CT

PostPosted: Mon Apr 18, 2016 8:30 pm
Reply with quote

Hi Mr sample, could you explain how did you know this program is running under CICS?
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


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

PostPosted: Mon Apr 18, 2016 8:55 pm
Reply with quote

This code should work for you. You'll need the CICS/SDFHMAC in SYSLIB concatenation when Assembling -

Code:

DWORD    DS    D
STATUS   DS    F
       
         DFHAFCD TYPE=DSECT            GENERATE 'AFCB' DSECT           

         STM   R14,R15,DWORD           STORE R14/R15
         DFHAFCD TYPE=LOCATE           LOCATE THE 'AFCB' (DFLT=R15)     
         USING DFHAFCB,R15             INFORM ASSEMBLER                 
         L     R14,AFCSA               LOAD THE CSA-ADDRESS             
         LA    R14,0(,R14)             CLEAR TOP-BIT                   
         LTR   R14,R14                 IS THE CSA PRESENT?             
         LA    R14,0                   ENSURE X'00'S                   
         JZ    CONTINUE                NO, BATCH ENVIRONMENT           
         CLC   =CL3'AFC',AFIDENT       CICS ENVIRONMENT?               
         JNE   CONTINUE                NO, BATCH ENVIRONMENT           
         LA    R14,1                   DEFAULT IS 'CICS' 
CONTINUE EQU   *
         DROP  R15                     DROP ADDRESSABILITY
         ST    R14,STATUS              STORE R14 IN FWORD
         LM    R14,R15,DWORD           RESTORE R14/R15

If the result in R14 (STATUS) is non-hexzeros, then the environment is CICS. Otherwise, it's Batch. I think Robert is OK with this.

HTH....
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 -> PL/I & Assembler

 


Similar Topics
Topic Forum Replies
No new posts Getting OUTREC - SHORT REC error for ... DFSORT/ICETOOL 12
No new posts Error while fetching the record from ... COBOL Programming 3
No new posts IEF085I REGION UNAVAILABLE,ERROR CODE... Java & MQSeries 0
No new posts S722 abend and ESTAE ABENDS & Debugging 1
No new posts How to determine is PDS member is bei... CLIST & REXX 13
Search our Forums:

Back to Top