STXIT

Last updated August 07, 2021

STXIT is a macro instruction for the DOS/360 operating system for the IBM System/360 series of mainframe computers, and its successors on later mainframe series, and was also available for the UNIVAC Series 90 mainframes running its TOS/DOS operating system and later on its VS/9 operating system.

Background

The macro was an abbreviation of the term "Set Exit," and was used by programs written in assembly language. It is used to create a recovery routine in the event of program errors, similar to signal handlers in C and Try/Finally blocks in C++, Java and other object oriented languages.

The STXIT macro would provide an error recovery address for several major types of errors and certain operator signals. The errors covered depended upon the operating system. In general, the errors which it provided recovery included

address protection violate (accessing memory not owned by the application)
privilege violation (attempts to execute privileged instructions)
divide check (division by zero)
floating point check (floating point underflow or overflow)
timer runout (where a timer set by the program has expired) this particular interrupt is not actually an error, it is how a program responds to a watchdog timer
Interrupt resume, a function on the UNIVAC Series 90 where an interactive user has issued a break to a program to go to command mode, and issued an INTR command to cause the program to resume at the INTR point. If the program has not specified an INTR resume address, the INTR command is rejected. This is similar to the REENTER command on the RT-11 operating system on Digital computers.

The timer interrupt STXIT provided a mechanism for sampling program execution and was used by various legacy performance analyzers. Essentially a PSW was gathered for each time interval and used for later analysis to determine hot spots.

The program check STXIT provided a mechanism for program animation via the deliberate introduction of invalid opcodes (on the fly) to locations in the target programs. Once the exit recovery was entered, the original opcode would be restored ready for later resumption and a new location set.

Macro format

The format of the macro call depended upon the system it was used upon.

IBM DOS/VSE

For DOS/VSE it was one of two forms, either the macro call to establish (create) a STXIT routine to handle the appropriate event, or a macro call to de-establish (no longer handle) the event.^[1] To establish a STXIT routine, you would code:

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

Where

label - the optional label for this statement.
First argument: One of AB, IT, PC, OC, or TT must be used. These indicated which event you were handling for that particular STXIT call. Except for the AB handler, a STXIT handler routine completed through use of the EXIT macro. To handle more than one event, multiple invocations of the macro must be used, each one specifying a single event. These codes indicate:
- AB - Abnormal task termination. A task is being terminated other than because of issuance of a CANCEL, DETACH, DUMP, or EOJ macro. The OPTION= parameter is only used with this type of routine. This determines whether a program dump is issued once the STXIT routine completes. If an abnormal task termination occurs without a STXIT routine to handle it, the program is terminated with an error. AB is also used if there is a Program Check event during any other STXIT routine. An AB routine cannot exit to return to the failing program, the routine must complete with a request to terminate the program via an EOJ, CANCEL, DETACH or DUMP macro.
- IT - Interval Timer. The program created an interval timer and the amount of time to measure has expired. An Interval Timer event is ignored if no STXIT routine exists to handle it. If additional Interval Timer events occur while an Interval Timer event is being serviced, they are delayed until the routine exits. Return from the routine is to the instruction that would have executed.
- PC - Program Check. The program has executed an illegal instruction, used data in an unallowed manner, or otherwise had a programming error. The STXIT routine can provide a clean recovery of the program in such cases. If a Program Check event occurs when no routine is provided, the program is terminated with an error. If a Program Check event occurs during a STXIT routine (other than AB), the AB routine is invoked. Return from the PC routine is to the next instruction after the failing one, unless the STXIT routine terminates the program.
- OC - Operator communication. The Operator has pressed the request key and issued a MSG command. This is ignored if no STXIT routine exists to handle it. Return from the routine is to the instruction that would have been executed.
- TT - Task timer runout. If a Task Timer is enabled through the SETT macro, this routine is used to handle them. If a task timer event occurs and no STXIT routine exists to handle it, the timer is ignored. If a subsequent task timer occurs while in a task timer handler routine, the event is ignored. Return from the routine is to the instruction that would have been executed.
RoutineAddress - the label of the routine to handle this event
SaveArea - a 72-byte area in which to save contents of the general registers, with standard savearea construct (the first two words are back and forward pointers, and the remaining words are used to save registers 14,15 and 0 through 12. Each STXIT routine must have its own save area, as it is possible for one STXIT routine to be interrupted by another, for example, the interval timer might fire while handling a task timer. The STXIT routines registers are saved automatically there when the routine is invoked, and are restored automatically when the EXIT macro is issued
Everything beginning one space after the last parameter is a comment.

When a STXIT routine completes, it returns to the point where it was invoked via the EXIT macro to return to the appropriate point where called, unless it is an AB routine, in which case it is not permitted to return and must issue a termination macro (EOJ, CANCEL, DETACH or DUMP).

To de-establish, or cancel a STXIT routine, you would code:

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

to cancel the routine for that event. Everything beginning one space after the parameter is a comment.

IBM z/VSE

For z/System VSE, all STXIT functions provided previously by IBM DOS/VSE are still supported. In addition, a new STXIT macro function 'Disabled Timer Appendage (DIE)' is available, but only for use in Supervisor Mode (Key 0, PSW privilege bit =1).^[2] Format is:

label STXIT DIE,rtnaddr|(1)

Where DIE means the routine is to handle a "Disabled Interval timer Event", and rtnaddr is the address to handle the expiration of an interval timer when a Set TOD event is coded. The address may instead be specified as (1), meaning the address is stored in register 1. The routine is subject to strict restrictions including not changing any register contents or using most SVCs.

Univac VS/9

For Univac VS/9^[3] it was

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

Where

label was the optional branch label used for the instruction
STXIT is the name of the macro to the called
R is used to indicate the class of STXIT call to be made (there were other formats created later)
abend is the label of an optional routine used to handle abnormal termination, which is any program termination other than the TERM, EXEC or EOJ macro. The program has 30 seconds of cpu time or 5 minutes of wall-clock time to recover and terminate itself or request execution of a new program, or the program is terminated automatically. Failure to have an abend routine causes the program to be terminated with an E079 error. The abend handler cannot return to the program, it must terminate with TERM or EOJ (or execute another program with EXEC) when it completes. The abend handler is also called if a progcheck occurs in the progcheck STXIT routine; a progcheck during an abend routine terminates the program immediately with an EO79 error, allowing the user to request a PDUMP if desired, unless a shutdown is in progress in which case the EO79 error is displayed, and the program is cancelled without allowing the user to request a PDUMP, and the user is automatically logged off.
progcheck is the label of an optional routine used to handle program checks, which are any errors in the program. If a progcheck routine is not present, the abend routine is invoked; if no abend routine exists either, the program is terminated with an EO79 error and the user has the option of requesting a PDUMP. Return is to the instruction after the failing one unless this routine specifies a new address. A progcheck occurring in any STXIT routine except progcheck and abend is passed here; a program check during the program check handler causes the abend routine to be invoked. A program check during the ABEND handler causes the program to terminate.
intr is the label of an optional routine used to handle the INTR command from the user's terminal after the user presses the break key on the keyboard. If no INTR routine exists, an INTR command by the user is rejected but the user may issue the R command to resume at the point of interrupt. Return is to the instruction being executed when the user issued a break unless this routine specifies a new address.
setic is the label of an optional routine used if the program issued the SETIC macro to create an Interrupt Condition timer. The IC timer is ignored if no handler routine exists for it. Return is to the instruction after the interrupt occurs unless this routine specifies a new address.
time is the label of an optional routine used if the user issued a TIME= parameter when executing the program to indicate it should break when the amount of CPU time has been consumed. When the routine finishes, the program will break, and the user can issue an INTR command to invoke the INTR routine, or issue the R command to resume the program when the time interrupted. If no time routine exists, the break occurs normally.
shutdown is the label of an optional routine used if the system console operator has requested to shut down timesharing. The program has a short period to allow itself to clean up any necessary features and quit. When the routine completes, the program is terminated and the user automatically logged off. If no shutdown routine exists, the program is cancelled without warning and the user automatically logged off.
everything beginning one space after the last parameter was a comment.

As the STXIT macro on VS/9 was parameter based, missing entries had to be entered with commas, e.g. if only the third item was being handled, the format would be

      STXIT R,,,RTN1

To remove one or more handlers, the STXIT macro is re-invoked with a blank entry for the handlers to be removed. Only one STXIT macro call can be in effect at any time.

If a class of event is not being handled, it is omitted, and there would be two (or more) commas in a row to indicate this. An unhandled class of event causes that error to be handled by the operating system's "default" handler. For events representing critical errors (abend and progcheck), the program is terminated with an EO79 error and the user has the option to request a PDUMP; for non-critical events the event is ignored.

Later developments

Later error recovery systems would provide for specifying errors explicitly as opposed to by the position of the parameter on the STXIT macro.

Univac's VS/9 continued to support STXIT but also added the CRTN ("Contingency Routine") macro to provide even more powerful error recovery, as well as recovery of some errors which STXIT did not capture. Originally, CRTN and STXIT could not be used together. Later releases of the operating system provided for both; if a CRTN and a STXIT macro were both used, the CRTN handled any events not covered by STXIT; if both were used to cover an event, the STXIT routine handled the event and the CRTN routine was not invoked.

Related Research Articles

In digital computers, an interrupt is a response by the processor to an event that needs attention from the software. An interrupt condition alerts the processor and serves as a request for the processor to interrupt the currently executing code when permitted, so that the event can be processed in a timely manner. If the request is accepted, the processor responds by suspending its current activities, saving its state, and executing a function called an interrupt handler to deal with the event. This interruption is temporary, and, unless the interrupt indicates a fatal error, the processor resumes normal activities after the interrupt handler finishes.

In computing and computer programming, exception handling is the process of responding to the occurrence of exceptions – anomalous or exceptional conditions requiring special processing – during the execution of a program. In general, an exception breaks the normal flow of execution and executes a pre-registered exception handler; the details of how this is done depend on whether it is a hardware or software exception and how the software exception is implemented. Exception handling, if provided, is facilitated by specialized programming language constructs, hardware mechanisms like interrupts, or operating system (OS) inter-process communication (IPC) facilities like signals. Some exceptions, especially hardware ones, may be handled so gracefully that execution can resume where it was interrupted.

In computer programming, event-driven programming is a programming paradigm in which the flow of the program is determined by events such as user actions, sensor outputs, or message passing from other programs or threads. Event-driven programming is the dominant paradigm used in graphical user interfaces and other applications that are centered on performing certain actions in response to user input. This is also true of programming for device drivers.

A terminate-and-stay-resident program is a computer program running under DOS that uses a system call to return control to DOS as though it has finished, but remains in computer memory so it can be reactivated later. This technique partially overcame DOS's limitation of executing only one program, or task, at a time. TSRs are used only in DOS, not in Windows.

In computing, a system call is the programmatic way in which a computer program requests a service from the kernel of the operating system on which it is executed. This may include hardware-related services, creation and execution of new processes, and communication with integral kernel services such as process scheduling. System calls provide an essential interface between a process and the operating system.

The Burroughs Large Systems Group produced a family of large 48-bit mainframes using stack machine instruction sets with dense syllables. The first machine in the family was the B5000 in 1961. It was optimized for compiling ALGOL 60 programs extremely well, using single-pass compilers. It evolved into the B5500. Subsequent major redesigns include the B6500/B6700 line and its successors, as well as the separate B8500 line.

Disk Operating System/360, also DOS/360, or simply DOS, is the discontinued first member of a sequence of operating systems for IBM System/360, System/370 and later mainframes. It was announced by IBM on the last day of 1964, and it was first delivered in June 1966. In its time, DOS/360 was the most widely used operating system in the world.

A watchdog timer is an electronic or software timer that is used to detect and recover from computer malfunctions. Watchdog timers are widely used in computers to facilitate automatic correction of temporary hardware faults, and to prevent errant or malevolent software from disrupting system operation.

Signals are a limited form of inter-process communication (IPC), typically used in Unix, Unix-like, and other POSIX-compliant operating systems. A signal is an asynchronous notification sent to a process or to a specific thread within the same process to notify it of an event. Signals originated in 1970s Bell Labs Unix and were later specified in the POSIX standard.

An interrupt vector table (IVT) is a data structure that associates a list of interrupt handlers with a list of interrupt requests in a table of interrupt vectors. Each entry of the interrupt vector table, called an interrupt vector, is the address of an interrupt handler. While the concept is common across processor architectures, IVTs may be implemented in architecture-specific fashions. For example, a dispatch table is one method of implementing an interrupt vector table.

Exception handling syntax is the set of keywords and/or structures provided by a computer programming language to allow exception handling, which separates the handling of errors that arise during a program's operation from its ordinary processes. Syntax for exception handling varies between programming languages, partly to cover semantic differences but largely to fit into each language's overall syntactic structure. Some languages do not call the relevant concept "exception handling"; others may not have direct facilities for it, but can still provide means to implement it.

The Interrupt Descriptor Table (IDT) is a data structure used by the x86 architecture to implement an interrupt vector table. The IDT is used by the processor to determine the correct response to interrupts and exceptions.

Basic Assembly Language (BAL) is the commonly used term for a low-level programming language used on IBM System/360 and successor mainframes. Originally, "Basic Assembly Language" applied only to an extremely restricted dialect designed to run under control of IBM Basic Programming Support (BPS/360) on systems with only 8 KB of main memory, and only a card reader, a card punch, and a printer for input/output — thus the word "Basic". However, the full name and the initialism "BAL" almost immediately attached themselves in popular use to all assembly-language dialects on the System/360 and its descendants. BAL for BPS/360 was introduced with the System/360 in 1964.

In computer science, the event loop is a programming construct or design pattern that waits for and dispatches events or messages in a program. The event loop works by making a request to some internal or external "event provider", then calls the relevant event handler. The event loop is also sometimes referred to as the message dispatcher, message loop, message pump, or run loop.

In programming and software design, an event is an action or occurrence recognized by software, often originating asynchronously from the external environment, that may be handled by the software. Computer events can be generated or triggered by the system, by the user, or in other ways. Typically, events are handled synchronously with the program flow; that is, the software may have one or more dedicated places where events are handled, frequently an event loop. A source of events includes the user, who may interact with the software through the computer's peripherals - for example, by typing on the keyboard. Another source is a hardware device such as a timer. Software can also trigger its own set of events into the event loop, e.g. to communicate the completion of a task. Software that changes its behavior in response to events is said to be event-driven, often with the goal of being interactive.

A Supervisor Call instruction (SVC) is a hardware instruction used by the System/360 family of IBM mainframe computers up to contemporary zSeries, the Amdahl 470V/5, 470V/6, 470V/7, 470V/8, 580, 5880, 5990M, and 5990A, and others; Univac 90/60, 90/70 and 90/80, and possibly others; and the Fujitsu M180 (UP) and M200 (MP), and others. It causes an interrupt to request a service from the operating system. The system routine providing the service is called an SVC routine. SVC is a system call.

A process is a program in execution. An integral part of any modern-day operating system (OS). The OS must allocate resources to processes, enable processes to share and exchange information, protect the resources of each process from other processes and enable synchronization among processes. To meet these requirements, the OS must maintain a data structure for each process, which describes the state and resource ownership of that process, and which enables the OS to exert control over each process.

The PDP-11 architecture is a CISC instruction set architecture (ISA) developed by Digital Equipment Corporation (DEC). It is implemented by central processing units (CPUs) and microprocessors used in PDP-11 minicomputers. It was in wide use during the 1970s, but was eventually overshadowed by the more powerful VAX-11 architecture in the 1980s.

The IBM System/360 architecture is the model independent architecture for the entire S/360 line of mainframe computers, including but not limited to the instruction set architecture. The elements of the architecture are documented in the IBM System/360 Principles of Operation and the IBM System/360 I/O Interface Channel to Control Unit Original Equipment Manufacturers' Information manuals.

DioneOS is a multitasking preemptive, real-time operating system. The system is designed for Texas Instruments MSP430x microcontrollers. Target microcontroller platform has limited resources, i.e. system clock frequency in tens of MHz and memories amount from tens to a few hundreds KB. The system is adapted to such conditions by providing its compact and efficient image. The efficiency term means here minimization of additional CPU load caused by the system usage. According to this definition, the system is more effective when it consumes less CPU time for execution of its internal parts.

References

↑ DOS/VSE Macro Reference, Doc. No. GC24-5140-0, International Business Machines Corporation, Endicott, New York, 1979.
↑ IBM z/VSE VSE Central Functions Supervisor Calls and Internal Macros, International Business Machines Corporation, White Plains, NY, 1985, 2007
↑ Univac VS/9 Programmer's Manual, Sperry Univac, Cinnaminson, NJ, 1974

This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.

[1] DOS/VSE Macro Reference, Doc. No. GC24-5140-0, International Business Machines Corporation, Endicott, New York, 1979.

[2] IBM z/VSE VSE Central Functions Supervisor Calls and Internal Macros, International Business Machines Corporation, White Plains, NY, 1985, 2007

[3] Univac VS/9 Programmer's Manual, Sperry Univac, Cinnaminson, NJ, 1974

[1]

[2]

[3]