NonStop User Exits › NonStop Server User Exits › TIRELOG—Server Error Logging and Error Token Creation Exit › Purpose

Purpose

This exit serves two purposes:

• Error logging at the server
• Creation of an error token for transmitting to the client

This exit is called by the server to handle server errors that are encountered during the execution of a distributed processing server that cannot be handled by the runtime or generated code, and normally result in the termination of the application. For example, prior to the execution of a server procedure step, the server extracts view data from the client message and places it in the target procedure step's view. If this extraction fails because of a mismatch between the client definition and the server definition an error response message is created and returned to the client.

The default implementation of this exit returns to the caller without logging the error. It is up to the developer of this user exit to determine what information should be logged and how it should be logged. Some users can choose to log only certain errors; others can choose to log all errors. On some systems, the log can be implemented as a file. To log a server error, simply format the information you wish to log and write it to a file. On other systems, the log can be implemented using system-specific features such as a CICS temporary storage queue (TSQ) as found on z/OS.

To create an error token, move text data to the area pointed to by the elog_error_token member of the TIRELOG_CMCB structure passed into this exit. The error token area is 4097 bytes and must be null-terminated. The error token, which goes through codepage translation when it is transmitted to the client, can be used on the client to customize how the error is handled.

For example, you can modify this exit to return an error token of "RETRY" whenever a certain database contention error occurs. This error token is passed to the client error-handling exit (WRSRVRERROR or WRASYNCSRVRERROR), which makes the final decision on how to handle the error. You can modify the client error-handling exit to reinvoke the flow or USE whenever the error token is "RETRY." This server error-logging exit is called after the error response message is created but before it is transmitted to the client.