In order to be able to react to certain events in a program, openUTM permits the use of what are known as event functions. Unlike “normal” program units which are called by specifying a transaction code, openUTM starts these program units when certain events occur.
There are two different types of event functions:
event exits, which must not contain any KDCS calls and
event services, which must contain KDCS calls.
Note for BS2000 systems
Since STXIT routines such as those used on BS2000 systems are also event-driven, a description of these routines has also been included in this manual in section "STXIT routines (BS2000 systems)". The section "Event handling in ILCS programs (BS2000 systems)" deals with event handling in ILCS programs.
Event exits:
INPUT | This event exit is called with input from a data display terminal. |
| HTTP | This event exit is called when the input message is read from and before the HTTP response is sent to an HTTP client. |
START | These event exits (up to 8) are called at each start of the application program. |
SHUT | These event exits (up to 8) are called at each termination of an application work process, including at PEND ER. |
VORGANG | This program unit is called at the start and the end of a service, and also in the case of incorrect termination or termination caused by loss of connection or in the case of a service restart. |
FORMAT | Only on BS2000 systems: This event exit is called if a message is entered or output which you then want to format using a formatting routine of your own (-format). |
Event services:
BADTACS | This dialog service is called whenever an invalid transaction code is entered at a terminal or a TS application or data protection is violated. |
MSGTAC | This asynchronous service is called whenever openUTM outputs a message with MSGTAC defined as its destination (see the openUTM manual ”Messages, Debugging and Diagnostics”, the section describing the modification of output messages). |
SIGNON | This dialog service is called whenever a terminal user, a TS application or a UPIC client signs on to the application. The prerequisite for this is that a signon service must be generated for the transport system access point via which the client signs on; in addition, UPIC= YES must be generated in the SIGNON statement for UPIC clients. |
For each transport system access point of a UTM application (generated with MAX APPLINAME or BCAMAPPL), a separate sign-on service can be generated (see the SIGNON-TAC parameter of the BCAMAPPL statement in the openUTM manual “Generating Applications”). |
Database calls are only allowed in the program units for VORGANG, BADTACS, MSGTAC and SIGNON, and not in the case of program units for INPUT, START and SHUT.
Only on BS2000 systems: Database calls are not permitted in FORMAT program units.