Natural abend handler

, ,
1

In all Natural versions since Natural 2, we have amended the code delivered in NCISTART (subsequently NCIROOT with Natural 4.2). We did this to provide amend information in case of Natural abends within CICS. With versions beyond Natural 4.2.6 this will not be possible. It is impossible to execute USR* type routines when Natural has abended with an S0C4 or similar abend as Natural is abending.

This reduces our ability to provide abend information, we see this as a useful feature and would like to continue with this feature in a supported manner.

Brief Outline.
In our simple abend processing we amend the delivered code in NCIROOT to pass the address of the BB to our backend code called NAT4END, executed via parameter PROGRAM=NAT4END. NAT4END takes the BB and adds it to other abend information available from CICS and write to a Temporary Data queue. This TD queue is subsequently processed and the data recorded in an Adabas File, we can use this to provide abend information to users regarding their transactions. This is especially useful with regard to background or Asynchronous transactions. A small example;

Tran CICS-Prog Abend Term Time Date User Library Program Line
TOCL ADNATV4 ASRA TRFN 13:32:16 10023 CICSQ TRATLAS TR0010S1 770

For this example transaction TOCL executes Natural Nucleus ADNATV4, it abended ASRA actually S0C4. We have the Natural program executing at the time and the Library loaded and the line number directly from the BB. This enables us to provide diagnostics without recourse to reading the dump.
There are other things that could be added to this directly from the BB for example;

Subroutine Level.
GDA Active
For an S0C7 you could provide the name of the variable causing the abend.
Steplib details.

I am sure there are many more details available from the BB or addressed from here, there are also other CICS data that could be applied.
This will provide further dump diagnostic information for end users and on site Natural support, it should also reduce the number of incidents raised with support. It is a relatively simple amendment to the NCIROOT code and some small additions to the back end code delivered with MSADABAS.NCI426.SRCE(XNCIBACK).

Cheers Kev

2

a) this is not a NCI but a general Natural concern.
b) you can already today accomplish, what you want without modifying our sources: use the official RDC exit interface and intercept the ‘E’ = error event; this event is raised even with DU=ON; then look for the relevant Natural error code you are interested in, e.g. NAT095x, x=3, 4, 5, 6. in the RDC parms you already get data like user id, library id and active program etc. In addition relevant information about the abend can be picked up from IOCB as TPABCDE, CMESPSW, CMESREGS, CMESCSCT (csect where abend psw points to) and CMESDISP (offset into csect); this is mainly the info you see in DUMP ABND after a S0Cx abend.

3

Hi Klaus

Thank you for your reply, I have been holding off replying until we had a chance to test using our SYSRDC exit. We can indeed gather the required information from SYSRDC and this is appears to be an excellent solution to our issue.

Cheers Kev