openUTM guarantees that no data will be lost, even if the local resources fail. For instance, it offers protection against the problems described below.
Operating system error
If an operating system function informs openUTM that an error has occurred, then this error is handled as an internal openUTM error, i.e. before any damage can be done, openUTM immediately terminates the application with an appropriate error code.
Disk failure
To enhance data protection, it is possible to mirror the KDCFILE on different drives (hot standby). This may result in a very slight increase in input/output times (by no means doubled), but the effect on performance is negligible.
Hardware errors in terminals
If a terminal fails, the user can simply move to another terminal, sign on there under his/her user ID, and resume the service started.
Even if the application operates without user IDs, the terminal user can immediately continue working on another terminal if his/her terminal breaks down. In this case, however, administration must assign the user another terminal.
If a defective terminal cannot receive asynchronous messages, it is possible to assign an intact terminal to the relevant logical access point (LTERM partner) by administration. The asynchronous messages are then output on this terminal.
Network failures or serious network faults
In the event of a network failure, the relevant network connections to openUTM are shut down.
Loss of terminal connections
When the (sub)network has been restored, terminal users can sign back on to the UTM application and continue working.
Loss of printer connections
A network failure or a serious network fault can result in the loss of printer connections. This also occurs if a logical print acknowledgment is not returned. openUTM uses logical print acknowledgments to monitor the printing of messages. If a requested print acknowledgment
is not returned within a defined period, openUTM shuts down the connection to this printer.
In all of these cases, openUTM automatically attempts to reestablish the connection. These attempts are repeated at defined intervals. If the connection still cannot be reestablished, the administrator can assign another printer. If you have a printer pool, the messages are automatically output to another printer.
After the connection has been reestablished, the entire print process is repeated in the following situations:
The message to be printed was sent in full, but a print acknowledgment was not returned within the defined period.
Several parts of a message were sent, but the entire message was not printed in full.
To indicate the possibility of duplicate messages, openUTM sends an appropriate message with each output attempt.
Errors that do not result in a loss of connection
Errors can occur when inputting or outputting messages. These may be due to hardware errors in terminals or printers, or network faults. During input, such errors are detected by the formatting system. In this case, openUTM outputs the last output message again, so that the terminal user can repeat his/her input. If the terminal user identifies faulty output messages (e.g. smudge characters), he/she can output the last message again (KDCDISP user command).
If a printer is found to be faulty before openUTM has finished printing the entire print message, then openUTM will clear down the connection. The message is output again as soon as the connection has been reestablished.