To solve ASRA abend, first we need to identify where it actually occurs.
To locate problem we can make use of debugging tools like Xpeditor, cedf. Most of the times even normal text send stmts would help us.
Once we got the problem area, we would come to know the causes for the ASRA abend. Then we can easily solve that.
Understanding ASRA Abend:
Addressing Exception:
The ASRA abend is triggered when a program attempts to access or reference memory locations outside its valid address range. This could occur due to an invalid memory address calculation or pointer manipulation.
Arithmetic Exception:
In some cases, ASRA can also indicate an arithmetic exception, such as division by zero, overflow, underflow, or invalid arithmetic operation.
Common Causes:
ASRA abends can result from programming errors, data anomalies, incorrect usage of pointers or arrays, inadequate error handling, or unexpected conditions during program execution.
Steps to Resolve ASRA Abend:
Review Abend Messages:
Examine the ASRA abend message and associated dump to identify the specific instruction, data, or memory access causing the exception.
Code Inspection:
Review the COBOL program code, focusing on arithmetic operations, array or pointer manipulations, and memory access routines.
Verify that calculations involving memory addresses, indices, or pointers are correct and within valid ranges.
Data Validation:
Implement data validation checks to ensure that input data is valid and does not lead to arithmetic exceptions or invalid memory accesses.
Error Handling:
Enhance error handling mechanisms in the program to detect and handle arithmetic or addressing exceptions gracefully.
Include explicit checks for division by zero, overflow, underflow, and other arithmetic conditions that may cause ASRA abends.
Boundary Conditions:
Pay attention to boundary conditions, especially in loop iterations, array accesses, or data processing routines, to prevent out-of-bounds memory access.
Testing and Debugging:
Use debugging tools, simulation environments, and test cases to reproduce the ASRA abend scenario and identify the root cause.
Conduct thorough testing with various input data sets to validate program behavior and address potential exceptions.
From the above info. from page 1 of this abend, we can determine the following (and more):
NERACTSI is the applid of the running CICS region.
(CICSTSTI is the UFCNS jobname, btw.)
The CICS abend code is "ASRA" (CODE=ASRA).
The CICS transaction identifier is "NESW" (TRAN=NESW).
The CICS program identifier is DCNESW00 (RIDS/DCNESW00).
The second fullword of the PSW (Program Status Word) tells us that the NSI (Next Sequential Instruction) after the failing instruction is at x'8EDF0032'. Recall that a fullword (or simply "word") is 4 bytes. A halfword is 2 bytes. A byte is 8 bits or 2 "nibbles". x'C7' represents one byte or 2 nibbles. The bit representation of x'C7' is 11000111.
The third full word of the PSW tells us that the failing instruction length is 6 bytes and the type of program interrupt is "7" (commonly known as "0C7" or "S0C7" or "sock seven").
first second third fourth
fullword: fullword: fullword: fullword:
PSW 079D1000 8EDF0032 00060007 057E5000
| | |
| | type
| length
|
high order
32-bit is on,
so assume
31-bit mode
From the above info., we can determine the following (and more):
An abend (code 0C7/AKEA) has occurred at offset X'00000EA2' in program DCNESW00. Look for the string DCNESW000C7/AKEA in the display portion of the dump, then look for the first full word after this string in the hex portion of the dump: 00000EA2. This is the offset from the load point (vs the entry point) of the problem program (DCNESW00).
To determine the offset from the entry point of the program we need to look at the LINKEDIT/BINDER listing and subtract the offset of our program, x'20', from x'EA2', giving x'E82':
DFSMS/MVS V1 R5.0 BINDER 16:23:16 TUESDAY AUGUST 8, 2000
BATCH EMULATOR JOB(DCNESW00) STEP(COBOL3 ) PGM= IEWL PROCEDURE(LKED )
IEW2278I B352 INVOCATION PARAMETERS - LIST,MAP,XREF,LET,RENT,AMODE=31,RMODE=ANY
Another way to determine the failing instruction offset (without using the LINKEDIT/BINDER listing) is as follows:
Subtract the entry point (ENTRY PT) of DCNESW00 from the PSW. Both the load point (LOAD PT.) and entry points of DCNESW00 are listed in the "MODULE INDEX" portion near the end of the CICS transaction dump listing as follows:
----- MODULE INDEX -----
LOAD PT. NAME ENTRY PT LENGTH
0EDEF190 DCNESW00 0EDEF1B0 00003B70
The PSW at the top of the transaction dump listing contains 8EDF0032 and the entry point from the module index is 0EDEF1B0. Because IBM uses 31-bit addressing (instead of 32-bit addressing), we ignore the high order bit of the PSW and subtract the entry point address x'0EDEF1B0' from the second full word of the PSW x'0EDF0032' resulting in x'E82'. Recall that this is the same offset that we obtained above.
There will be many programs (modules) listed in the MODULE INDEX of a dump. A useful technique is to position yourself at the bottom of the dump and then do a 'find program prev' to find the program in the module index.
Next, we need to look at the COBOL compilation listing and the COBOL LIST option "assembler" option listing for x'000E82', where we see an UNPK instruction when the COBOL ADD verb was compiled at statement 000513 (suspiciously in a paragraph labeled "4700-DATA-EXCEPTION"):
[snip]
000074 WORKING-STORAGE SECTION.
[snip]
000115 10 WS-RECEIVE-COUNT PIC X(02) VALUE SPACES. BLW=0000+3A7,0000347 2C
IMP
000147 05 WS-READ-COUNT PIC 9(4) VALUE ZERO. BLW=0000+408,0000000 4C
IMP
[snip]
000265 PROCEDURE DIVISION using dfheiblk dfhcommarea.
[snip]
000510 4700-DATA-EXCEPTION.
000511
000512 MOVE "++" TO WS-RECEIVE-COUNT. 115
000513 ADD WS-RECEIVE-COUNT-PIC9 TO WS-READ-COUNT. 134 147
[snip]
000512 MOVE
000E6C D201 23A7 A614 MVC 935(2,2),1556(10) (BLW=0)+935 PGMLIT AT +1428
000513 ADD
PP 5688-197 IBM COBOL for MVS & VM 1.2.2 DCNESW00 Date 08/08/2000 Time 16:23:11 Page 45
000E72 F223 D210 2408 PACK 528(3,13),1032(4,2) TS2=24 WS-READ-COUNT
000E78 960F D212 OI 530(13),X'0F' TS2=26
--> 000E7C FA21 D210 A612 AP 528(3,13),1554(2,10) TS2=24 PGMLIT AT +1426
000E82 F332 2408 D210 UNPK 1032(4,2),528(3,13) WS-READ-COUNT TS2=24
000E88 96F0 240B OI 1035(2),X'F0' WS-READ-COUNT+3
000E8C 47F0 BDB2 BC 15,3506(0,11) GN=18(0015B2)
000E90 GN=17 EQU *
From the above COBOL listing(s), we can determine:
Since the NSI is at offset x'E82', the failing instruction is the AP (Add Packed/Decimal) at offset x'E7C', which is a 6 byte instruction. Recall that we had already determined that the length of the failing instruction was 6 bytes, based upon the 2 high order bytes of the third full word of the PSW containing 0006.
Adding "++" to zero caused this data exception. We can confirm this by closer analysis of the contents of the storage referenced by the AP instruction. Here's some of the storage addressed by register 10 (R10/"A") and register 13 (R13/"D"):
R10+612 (x'0EDEF8DE'):
