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 '.
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
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.
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
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.
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
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.
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
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 -
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.
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.
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
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.
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.
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
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
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
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.
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
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.
