Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

ASRA Abend CODE 0C7/AKEA

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> CICS
View previous topic :: :: View next topic  
Author Message
bhavant

New User


Joined: 24 Aug 2007
Posts: 5
Location: India

PostPosted: Wed Sep 07, 2011 12:12 am    Post subject: ASRA Abend CODE 0C7/AKEA
Reply with quote

Hi,
A Program of mine is giving ASRA ABEND -- (CODE 0C7/AKEA) in production. As this said 0C7 I thought it might be due to a data error and synced all the required data for the particular transaction to the Test region and ran the process, it did not ABEND!! icon_exclaim.gif
Is there any other thing, other than data, which might cause ASRA? Please help.

I ran the process on Intertest, on the test region. Would this have blocked the ABEND? If yes, can you please tell me the options that I can set to stop INTERTEST from blocking the ABEND?

Any ideas on how to proceed would be much appreciated...

Thank you.....
Back to top
View user's profile Send private message

Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8054
Location: East Dubuque, Illinois, USA

PostPosted: Wed Sep 07, 2011 12:34 am    Post subject:
Reply with quote

If the ASRA was a S0C7 abend (the CICS message should tell you for sure), then it was a data exception -- period. S0C7 means a packed decimal (COMP-3 in COBOL) variable had non-numeric data in it.

CICS uses ASRA to indicate a program problem -- you MUST look at the output message(s) to see what the specific cause is. If the abend is something other than a S0C7 abend, then the cause might not be data.

I have seen cases where running the debugger kept an abend from happening, but those cases are quite rare and always are terminal-related. An S0C7 abend could be terminal-related but the likelihood is fairly low.

Start by looking at the CICS messages to get the program name and offset where the abend occurred. Find out which line of code is at that offset of that program and start looking at what could cause the observed behavior (the abend).
Back to top
View user's profile Send private message
bhavant

New User


Joined: 24 Aug 2007
Posts: 5
Location: India

PostPosted: Wed Sep 07, 2011 1:01 am    Post subject:
Reply with quote

This is statement in the CICS log
AN ABEND (CODE 0C7/AKEA) HAS OCCURRED AT OFFSET X'000037F6'

So I think this is a data exception. I will try to see the statement for offset mentioned above and check the data.

Thank you.. ll get back with updates...
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


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

PostPosted: Wed Sep 07, 2011 5:14 am    Post subject: Reply to: ASRA --- Help
Reply with quote

Re-compile the program, using the compile options LIST,NOOFFSET to generate the Assembler expansion.

Although you may find the offset of the VERB, the problem you may run into is that the S0C7 may have occurred within an intermediate compiler workarea within the VERB itself, such as a complicated COMPUTE.

Mr. Bill
Back to top
View user's profile Send private message
Ed Goodman

Active Member


Joined: 08 Jun 2011
Posts: 556
Location: USA

PostPosted: Wed Sep 07, 2011 8:03 pm    Post subject:
Reply with quote

One thing that bites us is that folks use a different set of options when they re-compile the program for Intertest/Expeditor/DebugTool.

One of the biggest culprits is NUMROC. Having this set to NOPFD in testing will prevent a S0C7 when that same data will abend in prod using PFD.

When you recompile, make sure that the options in effect match the ones in the production listing of the problem program. The only differences should be the ones needed by your debugger, such as LIST or NOOFFSET.
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


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

PostPosted: Wed Sep 07, 2011 11:10 pm    Post subject: Reply to: ASRA Abend CODE 0C7/AKEA
Reply with quote

Ed,

PFD will not initially raise a S0C7 on bad decimal-data, whereas, NOPFD will immediately raise a S0C7, such as on a COMPARE.

PFD will use a CLC, whereas, NOPFD will use a CP. CLC's will never raise a S0C7.

Note that ultimately, a S0C7 will be raised on bad decimal-data, even though PFD is used.

It's postponing the inevitable.... icon_wink.gif

Mr. Bill
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7315

PostPosted: Thu Sep 08, 2011 3:36 am    Post subject: Reply to: ASRA Abend CODE 0C7/AKEA
Reply with quote

Both PFD and NOPFD can generate CPs and CLCs.

NOPFD does, to my mind, two different sorts of "sign-fixing" (aka "rectification"). The one for unsigned fields is the problem with the abend/noabend situation, as it actually changes the data potentially from the non-presence of any sign at all.

Say you have an unsigned packed field containing space, or low-values. With NOPFD, the sign will be rectified to an F before each use (and after), thus there will be no abend. With unsigned-to-unsigned comparison, NOPFD will use CLC anyway, because it knows it can rely on the Fs in both fields.

With PFD, no rectification for unsigned fields so CP is used if signed is compared to unsigned, so abend (S0C7). Unsigned to unsigned will use CLC, so no abend on comparison, but abend on calculation (S0C7)with the unsigned field.

When the target is an unsigned field, PFD will ensure "F". Even if the source is unsigned.

If fields always conform to PICTURE, (fields are numeric and have a correct sign given how it is defined) then both work, though NOPFD generates more code. Neither are very susceptible to IBM's optimisation, NOPFD because there is not much you can do and keep the variety of signs permissable, PFD because it is already pretty hot.

If fields don't confirm to picture (ie they would fail the NUMERIC test) then you have differences in the two options. PFD good on unsigned (abend if sign a mess) NOPFD good on signed (will abend on compare).

Of course the problem with CLC on packed fields with PFD is if a signed field gets a non-C-or-D in the sign. With the CLC, the result of the comparison will be incorrect, logically. Two fields with the same value, one positive and one unsigned, will not be treated as equal. With NOPFD, CP will be used, and the results of the comparison will be correct.

Overall, neither are brilliant choices :-) But what can you do?

I think I prefer PFD (but am open to persuasion) as long as I "trust" the data - which is why I'm interested in knowing of occasions where "F"s get into signed fields.

One thing for sure, I'd use the same NUMPROC option in all environments, the difference in processing is too significant to let something through to the next environment and then compile with a different option of NUMPROC.

Also good to ensure that the compiler installation option NUMCLS matches with the chosen option of NUMPROC, so that the NUMERIC test knows which values are valid for signs.

Anyone done that lately?

IBM suggest using NOPFD. They "prefer" NOnPreFerreD. Except where performance is an issue (not just "I'd like it to go a little faster", but where it is a real issue) unless you are very sure your signed fields have the correct signs.

Why that mess was ever introduced in the Cobol compiler, I don't know.
Back to top
View user's profile Send private message
Jose Mateo

Active User


Joined: 29 Oct 2010
Posts: 110
Location: Puerto Rico

PostPosted: Fri Sep 09, 2011 8:24 pm    Post subject:
Reply with quote

Good day to all!

An abend AKEA must of the time it indicates corrupt storage which will cause a S0C7. Get a LE dump or CICS dump and do a trace back to the last module your abending program link to. Verify the process in that module to see if you bumped beyond a table or access a storaqe that wasn't suppose be alter. What might have happened is that your abending program got control from a link module, CICS verified it's kernel addresses and detected a corrupt address.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> CICS All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts Job failing with USER = 4093 REASON C... Pradeepa S ABENDS & Debugging 1 Wed May 17, 2017 3:35 pm
No new posts COBOL Code Parsers and Lineage Establ... balimanja COBOL Programming 2 Tue May 02, 2017 3:30 am
No new posts Cobol upgrade - source code missing f... gthmrj IBM Tools 1 Wed Apr 26, 2017 6:04 pm
No new posts JCL to Set Return code based on DB2 S... vinu78 DB2 17 Mon Mar 13, 2017 9:47 pm
No new posts IMS region inactive - User abend code... gthmrj IMS DB/DC 5 Tue Mar 07, 2017 12:29 pm


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us