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

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


IBM Mainframe Forums -> CICS
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
jpreethi

New User


Joined: 31 Oct 2006
Posts: 10

PostPosted: Tue Nov 11, 2008 3:31 am
Reply with quote

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.
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Tue Nov 11, 2008 4:06 am
Reply with quote

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.
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


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

PostPosted: Tue Nov 11, 2008 4:59 am
Reply with quote

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
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


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

PostPosted: Tue Nov 11, 2008 5:10 am
Reply with quote

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).
Back to top
View user's profile Send private message
jpreethi

New User


Joined: 31 Oct 2006
Posts: 10

PostPosted: Thu Nov 13, 2008 1:31 am
Reply with quote

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.
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


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

PostPosted: Thu Nov 13, 2008 1:42 am
Reply with quote

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.
Back to top
View user's profile Send private message
jpreethi

New User


Joined: 31 Oct 2006
Posts: 10

PostPosted: Thu Nov 13, 2008 1:57 am
Reply with quote

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.
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


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

PostPosted: Thu Nov 13, 2008 2:06 am
Reply with quote

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.
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Thu Nov 13, 2008 2:37 am
Reply with quote

Hello,

To repeat:
Quote:
You may want to add a bit of your own diagnostic code to track the program flow...
I'd suggest putting in a constant "eyecatcher" field and behind it, space to place a "footprint". At different places in the code, move a different easily readable value to the footprint. When the abend occurs, find the "eyecatcher" in the dump and see what value is in the "footprint".

It should not take long to isloate where the abend occurs and once you know where it is happening, find the cause should follow. . .
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


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

PostPosted: Thu Nov 13, 2008 4:43 am
Reply with quote

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
Back to top
View user's profile Send private message
jpreethi

New User


Joined: 31 Oct 2006
Posts: 10

PostPosted: Thu Nov 13, 2008 6:42 am
Reply with quote

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.
Back to top
View user's profile Send private message
jpreethi

New User


Joined: 31 Oct 2006
Posts: 10

PostPosted: Fri Nov 14, 2008 1:45 am
Reply with quote

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.
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 -> CICS

 


Similar Topics
Topic Forum Replies
No new posts Using API Gateway from CICS program CICS 0
No new posts ISAM and abend S03B JCL & VSAM 9
No new posts Calling an Open C library function in... CICS 1
No new posts How to 'Ping' a CICS region in JCL CICS 2
No new posts Parallelization in CICS to reduce res... CICS 4
Search our Forums:

Back to Top