STXIT

STXIT

Company type	Macro instruction
Industry	Computer programming / Operating systems
Founded	1960s
Products	Error recovery routines in DOS/360, IBM System/360, UNIVAC Series 90, TOS/DOS, VS/9

STXIT represents a macro instruction utilized within the DOS/360 operating system for the IBM System/360 mainframe series and its later models. It is also implemented on UNIVAC Series 90 mainframes operating under TOS/DOS and the subsequent VS/9 systems.

Background

The term STXIT, an abbreviation for "Set Exit," was employed in assembly language to define recovery routines addressing program faults. Its function parallels that of signal handlers in C or the Try/Finally constructs found in contemporary languages such as C++, Java, among others.

STXIT assigned recovery addresses to handle critical errors and specific operator signals, with variations depending on the operating system. Typical error conditions managed include:

• address protection violations (accessing unauthorized memory regions)
• privilege violations (execution of privileged instructions without authorization)
• divide check errors (division by zero occurrences)
• floating point exceptions (underflow or overflow situations)
• timer runout events (expiration of timers set by programs), often used as watchdog mechanisms
• Interrupt resume on UNIVAC Series 90 systems, enabling users to interrupt and subsequently resume program execution interactively

The timer interrupt capability provided by STXIT allowed sampling of program execution, which legacy performance analyzers leveraged to detect frequently executed code segments. The program check STXIT facilitated program animation by deliberately triggering invalid opcode exceptions to invoke recovery routines.

Macro format

The syntax of the STXIT macro differs across operating systems.

IBM DOS/VSE

Within DOS/VSE, STXIT serves to either establish or remove a handler routine associated with particular events. To define a handler:

label STXIT {AB|IT|PC|OC|TT}, RoutineAddress, SaveArea [,OPTION= {DUMP|NODUMP}] comment

Details:

• label – optional statement identifier
• The first parameter specifies the event type:
  • AB – Abnormal task termination; requires the program to end via EOJ, CANCEL, DETACH, or DUMP macros; OPTION= determines whether a dump is generated.
  • IT – Interval Timer expiration; ignored if no handler exists; nested events are queued.
  • PC – Program Check triggered by illegal instructions or data misuse; can either recover or terminate; if occurring during another STXIT routine, invokes AB handler.
  • OC – Operator communication triggered by MSG command; ignored if no handler is present.
  • TT – Task timer runout; ignored if no handler; nested events are disregarded.

• RoutineAddress – label pointing to the handler routine
• SaveArea – a 72-byte storage area for preserving general registers; each routine requires its own due to potential nested interrupts
• Comments may follow after parameters

Handlers return control using the EXIT macro, except for AB handlers, which must conclude the program.

To disable a handler:

label STXIT {AB|IT|PC|OC|TT} comment

This statement removes handling capability for the specified event.

IBM z/VSE

In IBM z/System VSE, all STXIT functionalities from IBM DOS/VSE remain available. Additionally, a new STXIT macro named Disabled Timer Appendage (DIE) is introduced exclusively for Supervisor Mode operation (Key 0 with PSW privilege bit set to 1). Its syntax is:

label STXIT DIE,rtnaddr|(1)

Here, DIE addresses "Disabled Interval Timer Events," with rtnaddr specifying the routine managing interval timer expirations triggered by Set TOD events. The address may be (1), indicating it is stored in register 1. This routine must adhere to stringent restrictions, including prohibitions against modifying registers or invoking most SVC calls.

Univac VS/9

The STXIT macro in Univac VS/9 was structured as follows:

[label] STXIT R,[abend][,[progcheck][,[intr][,[setic][,[time][,[shutdown]]]] comment

Important parameters include:

• abend: An optional routine designated for handling abnormal terminations excluding TERM, EXEC, and EOJ. Programs are given limited CPU or elapsed time to either recover or initiate another program; failure to do so results in termination with an E079 error. The abend handler must either end the program or start a new one and cannot return control.
• progcheck: An optional routine to manage program errors. If omitted, the abend routine is triggered; if both progcheck and abend are absent, the program terminates with an EO79 error, allowing PDUMP requests. Control resumes at the instruction following the fault unless redirected elsewhere.
• intr: This handles INTR commands issued by user break keys. If no handler is provided, INTR commands are rejected but can be resumed using the R command.
• setic: Manages Interrupt Condition timers activated via the SETIC macro. If no handler exists, these interrupts are disregarded.
• time: Invoked when CPU time limits specified by the TIME= parameter are reached. This allows users to interrupt or continue execution.
• shutdown: Responds to system shutdown requests from the console operator, enabling cleanup operations before termination and automatic user logoff.

All parameters must be separated by commas; absent handlers are represented by empty fields (for example, STXIT R,,,RTN1). Only a single STXIT macro call can be active at once; invoking it again with empty parameters removes existing handlers.

Events without specific handlers default to the operating system’s management: critical errors (abend, progcheck) result in program termination with an EO79 error and PDUMP option; non-critical events are ignored.

Later developments

Subsequent error recovery mechanisms allowed specifying error types explicitly rather than relying on their position within the STXIT macro parameters.

Univac's VS/9 continued to support the STXIT macro and introduced the CRTN ("Contingency Routine") macro, which expanded error recovery functions and addressed situations beyond STXIT’s capabilities. Initially, CRTN and STXIT were incompatible; however, later OS releases permitted their simultaneous use. In such configurations, CRTN managed events not covered by STXIT, while overlapping events were handled exclusively by STXIT, bypassing CRTN entirely.