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!!
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...
Joined: 06 Jun 2008 Posts: 8167 Location: East Dubuque, Illinois, USA
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).
Joined: 14 Jan 2008 Posts: 2504 Location: Atlanta, Georgia, USA
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.
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.
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.
Joined: 29 Oct 2010 Posts: 112 Location: Puerto Rico
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.