openUTM offers various options for UTM-controlled queues and service-controlled queues. These options are integrated in the MQ calls of the KDCS interface.
Confirmation jobs
In addition to the message to the queue (“basic job”), you can define up to two confirmation jobs which are linked to the success or failure of the basic job. Confirmation jobs are possible for the following types of basic jobs:
background jobs
output jobs to terminals, printers or transport system applications
jobs to TAC queues
Confirmation jobs are initiated as soon as processing of the basic job is complete. They allow the job submitter to respond to a positive or negative job result. The confirmation job that does not apply, e.g. the negative confirmation job in the case of a successful basic job, is simply ignored. The basic job and the confirmation job are combined to form the job complex. What happens depends on what type of queue is involved:
Local background job
The positive confirmation job is started once the asynchronous service was terminated normally.
The negative confirmation job is started if the asynchronous service was terminated abnormally and if redelivery is not activated or the maximum number of redeliveries has been reached (see "Redelivery"). Abnormal termination may be due to a UTM call in the program (PEND ER/FR) or due to a major program error.
Background job to a remote service (remote queuing)
The positive confirmation job is started as soon as the job has been transferred successfully to the remote service queue.
The negative confirmation job is executed if the transfer fails despite repeated attempts.
Output job
The positive confirmation job is started once the positive print acknowledgment has arrived from the printer or printer administration.
The negative confirmation job is started:
after errors during message editing by VTSU-B or errors during formatting,
if the job is deleted during connection setup/shutdown by clients generated with RESTART=NO,
if a job was deleted by administration.
However, the negative confirmation job is not started for a negative print acknowledgment, for a timeout when waiting for the acknowledgment, or if the print job is repeated.
Job to a TAC queue
The positive confirmation job is started once the message has been read successfully in the TAC queue and the transaction has been terminated normally.
The negative confirmation job is started:
if the message is deleted with DADM DL and it is explicitly stated that the negative confirmation job is to be started (KCMOD=N),
if the transaction was rolled back during message processing and redelivery is not activated or the maximum number of redeliveries has been reached, see section "Redelivery".
Time control
It is possible to delay execution of background jobs, output jobs to LTERM partners and LPAP partners and jobs to TAC queues until a specified time. You can specify when the job is to be executed at the earliest or when the message can be read at the earliest. This can be defined relative to the time at which the job was submitted, or as an absolute value. This type of job is known as a time-driven asynchronous job. After the specified point in time, processing of the time-driven asynchronous job is started by openUTM as soon as the resources required to execute the job are available.
Redelivery
Redelivery of messages can be controlled for background jobs and messages to servicecontrolled queues. The following can be set by means of generation:
whether a message to an asynchronous service is redelivered after abnormal service end,
whether a message to a service-controlled queue is redelivered after a transaction has been rolled back,
the maximum number of redeliveries. Different values are possible for background jobs and service-controlled queues. Specifying an upper limit prevents, for example, endless loops.
The redelivery function ensures that messages are preserved after service termination/transaction rollback and are not immediately deleted. openUTM also makes available a redelivery counter that can be read by the program unit. This allows the program to detect “loop situations” and to respond appropriately.
If a message is redelivered, no negative confirmation jobs are activated.
Backing up incorrectly processed jobs in the dead letter queue
The dead letter queue is a TAC queue that is always named KDCDLETQ. The dead letter queue is always available and is used to save messages sent to transaction codes, TAC queues, LPAP or OSI-LPAP partners that could not be processed or delivered.
In the generation, the backing up of messages in the dead letter queue can be enabled or disabled for each message destination.
For asynchronous TACs and TAC queues, the backing up can be done as an alternative to redelivery or as a last fallback stage once the maximum number of redelivery attempts has been reached.
To have the option of processing the messages in the dead letter queue even after the errors have been resolved, you can assign the messages either to their original destination or to a new target. Note that when you assign a new destination, the messages can be moved only to a destination of the same type as the original destination, i.e., either TAC, LPAP, or OSI-LPAP partner.
The number of messages in the dead letter queue can be monitored with message K134.
| Information about activating and deactivating the backup of messages in the dead letter queue and monitoring the message volume can be found in the openUTM manual “Generating Applications” (parameter DEAD-LETTER-Q of the TAC, LPAP, and OSI-LPAP statement or parameter DEAD-LETTER-Q-ALARM in the MAX statement). Information about moving or deleting messages from the dead letter queue or avoiding a page pool bottleneck can be found in the openUTM manual „Programming Applications with KDCS”, see KDCS call DADM and “Page Pool Bottleneck“). |
Administration of message queues
The processing of messages and jobs in message queues can be influenced by means of UTM administration. This applies both to UTM-controlled queues and to service-controlled queues. An asynchronous job or a message in a USER queue, can, for example, be brought forward in the processing order or canceled. The KDCS call DADM is available for the administration of message queues (see the next section). Alternatively you can use the graphical administration workstation WinAdmin or WebAdmin for this purpose.