ASRA abend caused due to invalid values in DSA

Srikaanth S · New User Joined: 25 Nov 2011 Posts: 2 Location: India

Hi,
I need some help for an ASRA abend.We are not able to replicate the same in test regions.This abend occurs once in a while.It has been reported once or twice in every month.Please find the details regarding the AADF log:
An ASRA abend occurred in program ********. The abending transaction was
T*** running at terminal for user ID ******.

Analysis of error

The Numeric Compare instruction in error is located at offset 009F54 in
program ********.

Current values of fields on abending statement:

The first field is in error. The COMP-3 1st data field causing the error is
located in the Dynamic Storage Area addressed by program ********. The field
in error can be found in the program's "DSA" at displacement 00000418. This
field contains:

25B22C
A Data Exception is caused when a decimal instruction is attempted on a
field that does not contain valid packed data, eg. contains an invalid digit
(not 0-9), or its last byte contains an invalid sign (not A, B, C, D, E, or
F).
Next Sequential Instruction

The next sequential instruction to be executed in program ******** was at
displacement 00009F5A.

The program was compiled on 26FEB2011 at 11:35:19 and is 00C0A2 bytes long.
It is part of load module T8A5GTWK which was loaded from
****.****.CICS.LOADLIB.
It was link edited on 26FEB2011 and is 00CCF8 bytes long.
The program AMODE is 31 and RMODE is ANY.
The execution key for this program was USER_KEY.

Last Call or EXEC CICS Command

The last call or 'EXEC CICS' command was issued from program ******** at
displacement 00009630.

I am not able to track the valid values since the operands belong to DSA and not the working storage section.

Please find the AADF log regarding PSW:
To display Registers at abend, select REGS

Program Status Word at Time of Abend Program Information

PSW................. 079D1000 A72B1F7A
Instruction Length.. 0006 Program.. ********
Interrupt Code...... 0007 Offset... 00009F5A
Description......... Compare Decimal

Address Instruction Opcode D1(L1,B1),D2(L2,B2)
272B1F74 F924 D418 6531 CP 1048(3,13),1329(5,6)

The first operand was located at address 25B22C48 and contained -

25B22C * *

The second operand was located at address 272AA6A9 and contained -

00000010 0F * *

I have masked the program and dataset names due to security concerns.
Please help me in resolving it.
Is it due to the some invalid program storage movements which may have caused corruption in DSA?
Please let me know if some one has faced these kinda problems earlier(i.e. ASRA or SOC7 in DSA rather than working storage section or linkage section variables). Because the displacement shown for the next instruction is a simple move statement.
The transaction invokes a CWS-COBOL program to fetch the details and throw it back to the screen in the form of HTML page.

Thanks and Regards,
Srikaanth

Garry Carroll · Posted: Tue Nov 29, 2011 5:38 pm

The DSA refers to storagebwhich contains the program, the working storage the linkage section &c. You need to determine what instruction is at the offset given and see which fields are beinfg used. You are comparing what should be a packed decimal value with a packed decimal value of 100.

It looks like you have a storage overlay where the first operand is getting trashed somehow.

Garry.

Srikaanth S · New User Joined: 25 Nov 2011 Posts: 2 Location: India

Hi Garry,
The offset refers to a simple move statement where I don't think can be any chance of storage overlapping.
Please find the allocation of DSA (I got it from compile listing of the program):
*** DSA MEMORY MAP ***
DSALOC

00000000 REGISTER SAVE AREA
0000004C STACK NAB (NEXT AVAILABLE BYTE)
00000058 ADDRESS OF INLINE-CODE PRIMARY DSA
0000005C ADDRESS OF TGT
00000060 ADDRESS OF CAA
00000084 SWITCHES
00000088 CURRENT INT. PROGRAM OR METHOD NUMBER
0000008C ADDRESS OF CALL STATEMENT PROGRAM NAME
00000090 CALC ROUTINE REGISTER SAVE AREA
000000C4 ADDRESS OF FILE MUTEX USE COUNT CELLS
000000C8 PROCEDURE DIVISION RETURNING VALUE

*** VARIABLE PORTION OF DSA ***

000000D0 BACKSTORE CELLS FOR SYMBOLIC REGISTERS
000000F8 VARIABLE-LENGTH CELLS
00000100 VARIABLE NAME (VN) CELLS FOR PERFORM
00000200 PERFORM SAVE CELLS
00000418 TEMPORARY STORAGE-2
00000498 OPTIMIZER TEMPORARY STORAGE

The operands belong to the temporary storage-2 of DSA. Is there any way by which we can trace back using AADF to find out the exact source of error. I tried running in test region with inter-test but I am not able to replicate it in test regions.

Please let me know if there is any way of tracing the source of error with the help of AADF.As I mentioned in my earlier post, this abend occurs occassionally in the production region. It always comes up with the same offset.

Thanks and regards,
Srikaanth

Robert Sample · Posted: Tue Nov 29, 2011 6:31 pm

Bill Woodger · Posted: Tue Nov 29, 2011 6:43 pm

Recompile with the generated pseudo-assembler but all other compile options the same as the last compile. Check the program length. If equal, you can (probably) use it to check on the temporary-storage.

However, you have a CP which is abending. You state that you have tracked it back to a simple move. Don't go together, do they, those sentences?

You need to be certain about which bit of Cobol is causing the abend. If you are certain it is the move you have to explain away the CP.

You have Occurs Depending On(s) in the program. Any relationship to the field you fhink is abending?

Did the abends occur before the February re-complie? If not, likely to be to do with the changes then.

Of course, you can check all indexes/subsrcipts/ODO values.

Bill O'Boyle · Posted: Tue Nov 29, 2011 11:46 pm

If the failure is occurring on an entry in the ODO table (subscript value too high), first, initialize the entire ODO with a unique packed-decimal value, such as negative 9's, which would raise a not equal condition on the CP instruction but would not cause a S0C7.

After initialization, load the ODO table based upon the DEPENDING ON variable with the valid values and the remaining entries will be your chosen default.

If you do encounter a not equal condition against the chosen value, log the subscript value to ensure you haven't gone beyond the DEPENDING ON variable.

Mr. Bill