In an ILCS application, all interruptions are first rerouted to the ILCS event routines. Whether and how an event is handled depends on:
the event itself
the programming language in which the most recent active program is written
the event handling routines in the programs involved
the call sequence, if this contains different ILCS programming languages
Event handling variants:
The program unit (i.e. a program within the call sequence) or a runtime system incorporated in its call sequence handles the event and continues processing.
Within the framework of the program unit as described above, the event is not handled but is passed on to openUTM together with its context and event code.
Two distinctions must be drawn in this case:
It is an event of the class PROCHK or ERROR:
openUTM prepares the message K102 together with the context and IW passed to it. In this case, the IW is additional control element for the following PEND handling.
It is any OTHER EVENT:
If the event ’Other Event’ occurs, openUTM can only offer a stereotypical response and has to prevent the task from being terminated abnormally. The event code that is passed is not an IW in the sense used in STXIT - its value is of no significance to openUTM. In particular, it is important to prevent this event code, in its role as a control element in UTM PEND handling, from leading to incorrect interpretations.To enable UTM error handling to run correctly, the event code is therefore set to the value X’FF’. During continued processing, openUTM interprets this value as a (simulated) IW. In other words, if an OTHER EVENT is passed to openUTM, then openUTM behaves as though an STXIT event had occurred with IW=X’FF’.
In such cases, diagnosis has to based on the message that was output when the OTHER EVENT occurred by the corresponding language, the program unit or ILCS. If no such message is output, the STXIT event X’FF’ is displayed together with the UTM message K102...KDCIWFF.
The resulting user-dump contains the code KDCIWFF.
Within the framework of the program unit as described above, the event is interpreted, a message is output (if necessary) and the ILCS entry IT0TERM is called. This entry activates openUTM and simulates the event handling of a TERM UNIT=PROG. In this case, the event data for the primary interruption could only be derived from the UTM message issued by the program unit or from the corresponding language. openUTM issues the message K102... KDCIW90 (TERM), together with all register states up to the time of the IT0TERM call.
The resulting user-dump contains the code KDCIW90.An ILCS-internal error occurs:
ILCS branches to a defined UTM entry; openUTM sets an internal event code, IW=X’00’, which can have one of two meanings:
an ILCS-internal error occurred
the ILCS stacking chain has been interrupted.
openUTM outputs this IW=X’00’ in the message K102. In its function as a control element, this IW=X’00’ is interpreted by openUTM during further execution of the program as an IW=X’88’, i.e. the task is terminated with TERM UNIT=STEP.
STXIT events - how ILCS behaves if an error occurs
After STXIT events which ILCS or the EHL routines that were called are unable to process, ILCS closes its own STXIT and terminates the routine with EXIT CONTINUE=NO. In most cases, the same error will occur again immediately, whereupon other STXIT routines (e.g. those controlled by UTM) can handle the error. In isolated cases, such as an exponential overflow, the program environment (register states etc.) at the start of the ILCS STXIT routine will already have been modified in such a way that it is now no longer possible to reconstruct the error environment. Before the STXIT is terminated, ILCS uses the IW to check whether it is possible for the error to recur. If not, ILCS calls its program termination routine IT0TERM.
User-specific STXIT routines in an ILCS environment:
To ensure that STXIT routines are executed in the correct sequence in an ILCS program environment, you should register user-specific STXITs directly with ILCS by means of special assembler macros or C functions For details, see the relevant user manual for CRTE, ASSEMH and C.