To process a background job, the UTM application starts the asynchronous service at an appropriate time. This service performs all the steps required to complete the job.
An asynchronous service can be divided into several processing steps and transactions. When using the KDCS interface, it can also comprise several program units.
Figure 22: Structure of an asynchronous service initiated from a terminal
In the example in figure 22, a background job is sent from a terminal to an asynchronous service of the local application. The transaction code of the service and possibly a message are input at the terminal. openUTM automatically places the job in the corresponding queue, and starts the asynchronous service independently of the job submitter as soon as the required resources are available.
An asynchronous service can initiate its own asynchronous jobs. These can be output jobs or further background jobs. In the case of distributed processing, dialog jobs can also be sent to partner applications from an asynchronous service, i.e. the asynchronous service can start its own remote dialog services.
Figure 23: Asynchronous services that initiate their own jobs
In figure 23 - as in figure 22 - a background job is sent from the terminal to a local asynchronous service. This service in turn initiates a further background job, and sends an output job to a printer. Asynchronous service 2 starts its own remote dialog service in UTM application B. This application can be located on the same system as UTM application A, or on a remote system. Even in the case of more complex structures with numerous queues, you need not concern yourself with the queuing mechanism, as this is provided automatically by openUTM.