0C4/AKEA in CICS/ASM, no abend when CEDF

jpreethi · New User Joined: 31 Oct 2006 Posts: 10

Experiencing 0C4/AKEA in CICS/ASM tran/pgm.

DFHAP0001 TESTPPC1 An abend (code 0C4/AKEA) has occurred at offset X'FFFFFFFF' in module MYPGM.
DFHME0116 TESTPPC1
(Module:DFHMEME) CICS symptom string for message DFHAP0001 is PIDS/5655M1500 LVLS/640 MS/DFHAP0001 RIDS/DFHSRP PTFS/UK05645 AB/S00C4 AB/UAKEA RIDS/MYPGM ADRS/FFFFFFFF

1. When run through CEDF, record gets processed good. No abend.!!!
2. TRACE shows EXCP during PROGRAM CHECK
SRP *EXC* ABEND_ASRA MYPGM,FFFFFFFF,CICS
3. AUX TRACE gives a whole lot of info. Unable to understand.
AP 0781 SRP *EXC* - ABEND_ASRA PROGRAM(MYPGM )
OFFSET(FFFFFFFF) EXEC_KEY(CICS) KE_NUM-007C TCB-QR /009DCA78
RET-AB0CA81E TIME-09:50:09.0135731337 INTERVAL-00.0000114062

EXC* Address_is_outside_DSA FUNCTION(FREEMAIN) ADDRESS(00000000) CALLER(EXEC) EXEC_KEY(USER)

Imagining a possible storage violation. Working with CICS group, but still stagnant. Pls help.

dick scherrer · Posted: Tue Nov 11, 2008 4:06 am

Hello,

Is this a new/recently changed assembler program or has it run for a long time and now suddenly abends?

The code may have failed to initialize a register correctly or some register value is being used as an address when it should not.

If it was a recent change, compare the working source against the modified source. If this is a completely new program of any size, it may be a bit more tedious.

You may want to add a bit of your own diagnostic code to track the program flow if no one there can work with the aux trace.

Bill O'Boyle · Posted: Tue Nov 11, 2008 4:59 am

The address of X'FFFFFFFF' indicates that you have gone past the end-storage of a particular label or the end of of the program itself.

An S0C4 is what's referred to as a Protection Exception, because if this were a true Storage Violation, the ABEND message would be DFHSM0102 or DFHSM0103, accompanied by a given X'code'.

If this were COBOL, this would be akin (for example), to a LINKAGE SECTION field which had no addressability or you've tried to update this field beyond its own addressability.

HTH....

Regards,

Bill

Robert Sample · Posted: Tue Nov 11, 2008 5:10 am

I've also seen the X'FFFFFFFF' in LE programs with AMODE / RMODE problems (i.e., a 31-bit program calls a 24-bit program and passes data that the subroutine cannot access).

jpreethi · New User Joined: 31 Oct 2006 Posts: 10

Internal trace shows abend in DLIXPOST.

Analysis of the abend:

The Protection Exception occurs when the Storage Protect Key of an operand, instruction, or data does not match the program's protection key. This normally occurs by executing an instruction that either references or resides at an illegal storage location.

This error occured within a program but is probably caused by inadvertently overlaying the program with invalid data or branching to an incorrect address.

The abend occurred in program DLIXPOST at displacement 000446.

Robert Sample · Posted: Thu Nov 13, 2008 1:42 am

If the program is processing correctly when running through CEDF but not when running by itself, look at the maps and mapsets. Your normal map processing is being interrupted by CEDF so I suspect a map something is causing the S0C4 but CEDF keeps the storage problem from killing the transaction somehow. Especially look at SEND MAP and RECEIVE MAP length fields, and any GETMAIN and FREEMAIN lengths.

jpreethi · New User Joined: 31 Oct 2006 Posts: 10

Thanks Robert. No maps though.
Online ASM to process incoming records from VSAM file/queue.

Found some VSAM exceptions though, but as per CICS GETMAIN looks questionable. But they dont know to read the dump either. Any clue on what to decipher from those?

Also no source for DLIXPOST with me.

Just want to eliminate application program being the issue.

Robert Sample · Posted: Thu Nov 13, 2008 2:06 am

Sorry, I haven't used IPCS enough in the last few years to be much help at deciphering dumps. When I've got one in front of me, I can muddle through but long-distance dump reading would be way beyond my current abilities.

If it's running with CEDF, are you sure you're going through the entire set of data to eliminate the chance that only one particular record is causing the problem? Sadly, application programs are usually the issue -- there's not that many system problems that pop up suddenly.

Look at the usual suspects: lengths on reads (and writes perhaps), queue lengths, matching getmains and freemains, and make sure the correct field lengths are used. I've seen problems caused by someone using a half word instead of a full word for a length field.

dick scherrer · Posted: Thu Nov 13, 2008 2:37 am

Hello,

To repeat:

Bill O'Boyle · Posted: Thu Nov 13, 2008 4:43 am

If there's a commarea, in the TRACE, you'll find CICS issuing a GETMAIN for the commarea and then, at task termination, you'll find CICS issuing a FREEMAIN.

Surrounding GETMAIN'd storage are what's called "Rabbit Ears" (SAA's), which CICS uses to determine the length of the previously acquired storage. They are 8-Bytes in length and can be found just before and after the actual storage-area. The Customization Guide can give you the different formats, as the first byte of the "Rabbit Ear" relates to the type of storage, followed by the EIBTASKN in unpacked format.

However, you won't find these GETMAIN's and FREEMAIN's while working through this with CEDF as they are not issued as API's from the program.

Is offset 446 part of the original program or is it in the generated CICS EPILOGUE code and the end of the program?

I think there's a mismatch on the commarea and what the program "Thinks" it's receiving is too short and the program is trying to update beyond this end-address, because it doesn't know any better.

What's the value in EIBCALEN?

Do you have XPEDITER?

Whether you know this, you can setup breakpoints on offsets in XPED.

Is your program LE compliant?

In other words, did it contain the necessary Language Environment MACROS necessary to access LE Callable Service routines or is it just run of the mill CICS/Assembler?

When non-LE compliant CICS/ASSEMBLER is Linked-To by a HLL (such as COBOL), you need to preserve the contents of R12, because LE places the address of the LE 'COMMON ANCHOR AREA' DSECT (CEECAA) in R12 of the HLL and if it's corrupted, then the fun begins.

HTH....

Regards,

Bill

jpreethi · New User Joined: 31 Oct 2006 Posts: 10

I dont think the program even starts. This is all I have in links.

Program Link Summary

Called Called ------- Status ------- Calling Calling Return
Load Mod Program Load Mod Program Offset
DLIXPOST DLIXPOST Linked By SYSTEM

But the program gave a forced dump before FINAL return.

No XPED with ASM here. Found other transactions also has same abends.

jpreethi · New User Joined: 31 Oct 2006 Posts: 10

Thanks for all your replies.

Today we got a 3303 on a record, found bad record trying to update Read-Only database. But again this was today. But when this record was bypassed, all went fine.

This would probably explain the X'FFFFFFFF' and S0C4 and the program check. right?

But not the no abend in CEDF. Or other unrelated transactions (not using the PSB or DB) causing similar DLIXPOST abend.

Still confused, but happy this is over.