Event functions

To enable you to react systematically to certain standard situations, openUTM offers the option of using event functions. Unlike “normal” program units, which are called by specifying a transaction code, openUTM automatically starts these program units when certain events occur.

There are two types of event function:

• event services, which must contain KDCS calls

• event exits, which must not contain any KDCS calls

The use of all the event functions is optional. You specify which event functions are to be activated in a UTM application during generation.

Event services
BADTACS	The BADTACS dialog service is started by openUTM when a terminal user or a transport system application specifies an invalid transaction code. For instance, BADTACS can be used to output help information or user prompting to inform the user of the transaction codes available for starting services.
MSGTAC	The MSGTAC asynchronous service is started by openUTM when UTM messages occur in the application, to which the MSGTAC message line has been assigned in the message file. The MSGTAC event service can be used to automate administration (see also "Automatic administration"). In the event of misuse, for example, the relevant terminal or a transaction code that results in repeated errors can be automatically locked.
SIGNON	The SIGNON dialog service is started by openUTM when a terminal user, a transport system application or a UPIC client signs on to the UTM application. A number of SIGNON services can be defined: one for each transport system access point. This means that services can be designed differently depending on the partner type. If a SIGNON service is generated for a transport system access point, it will always be executed for the terminals and transport system applications that establish the connection to the application via this access point. However, it is only activated for UPIC clients if it has been generated to do so explicitly.

	The SIGNON dialog service allows you to customize the signon dialog for your application. For instance, in addition to the openUTM sign-on checks, you can carry out your own authorization checks (see also "System access control (identification and authentication)") or you can explicitly assign a UTM user ID to transport system applications in the sign-on service.
Event Exits
START	The START exit is called by openUTM when starting or reloading the application program in every process. It can be used to open local files, for example. Up to 8 different START exits can be defined.
SHUT	The SHUT exit is called by openUTM when terminating the application program in every process. It can be used to close local files, for example. Up to 8 different SHUT exits can be defined.
VORGANG	The event exit VORGANG could be assigned to each individual service during configuration of a UTM application. It is then called by openUTM when starting and terminating the service - this applies even for abnormal terminations and service restarts. With this event exit, it is possible to access the KB header and the standard primary working area. The Vorgang exit permits service-specific actions, e.g. the opening and closing of special resources for certain services.
INPUT	The INPUT exit is called each time an entry is made at the terminal. However, this does not apply for entries in the SIGNON event service. The INPUT exit allows you to define which actions are to be initiated by input at the terminal, e.g. startup of a service or execution of a user command. It also offers a great deal of flexibility when designing the user interface.
HTTP	The HTTP event exit is used to appropriately reformat input messages from HTTP clients for the program unit and output messages from the program unit to the HTTP client. The HTTP exit could be assigned to a TAC with the HTTP-DESCRIPTOR statement.

The FORMAT event exit is also available on BS2000 systems, and allows users to program their own formatting.