An asynchronous service starts with an asynchronous program unit. The program unit is assigned a transaction code TYPE=A (asynchronous) at generation. An asynchronous program unit does not only differ from a dialog program unit in its transaction code type, it is also differently structured.
Structure of an asynchronous program unit
Asynchronous programs do not have to read an input message or create an output message. In the first program unit of the first processing step you can issue an FGET call following an INIT. This call makes it possible to read the asynchronous message of the creator of the background. This may be:
a complete message
a message segment or
an empty message in cases where the job consists of one TAC only (e.g. created via a function key at the terminal).
These may be followed by any number of KDCS calls, with the exception of MGET. However, you can use an MGET call in a follow-up program or follow-up processing step.
You cannot use MPUT to send a response to the communication partner from which you received the asynchronous message. Since the service runs disconnected from the partner, the partner may no longer be connected to the application at the time of processing. However, you can send a message to the partner with FPUT or DPUT. This message will be inserted in the message queue assigned to the partner. An MPUT call is only permitted if the message is addressed to a follow-up program or a job receiver service.
The last UTM call in your program unit must be PEND, as described in section "Program framework". An asynchronous program is normally terminated with a PEND FI call. This also terminates the service. openUTM transfers any unsent messages to the partner or partners.
Other PEND variants are possible, such as PEND PA/PR/SP for program unit chaining, and PEND KP and RE for distributed processing. You can also use the PGWT KP, CM and RP calls in an asynchronous program unit (e.g. PGWT KP) if you want to terminate the processing step without terminating the program unit or the transaction in distributed processing.
An asynchronous service may be split into multiple program unit runs, and also into multiple processing steps in the case of distributed processing (see "Asynchronous service with multiple program units" or "Asynchronous services which also issue jobs").
Figure: Structure of an asynchronous program unit
Combined dialog and asynchronous program
You can assign multiple transaction codes to a program unit. It is also possible to assign a dialog TAC and an asynchronous TAC to the same program unit. This means that you can start the program in dialog mode or asynchronously. openUTM indicates the way the program unit was started in the KCPRIND field of the KB header: "A" for asynchronous, "D" for dialog. The program unit can evaluate this field and branches accordingly.
Figure: Dialog and asynchronous processing in a program
If the program in the diagram is started with TACD, FPUT is executed after PEND. This means that the same program unit is called again to process an independent second service. The processing of an asynchronous service outside the dialog program may lead to better response times in the dialog with the client.
Asynchronous service with multiple program units
An asynchronous service may be structured into multiple program units and transactions. The last program unit is terminated with PEND FI. In the preceding program units the PEND variants SP or PA/PA are possible.
PEND variants such as PEND KP or PEND RE which terminate a processing step are only possible within an asynchronous service if distributed processing is used (see diagram on next page).
Figure: Structure of an asynchronous service split into three program units
In the depicted example a background job is issued to an asynchronous job of the same application from a terminal. To do this, you have to enter the transaction code of this service and, if necessary, a message at the terminal. openUTM automatically places the job in the relevant queue and starts the asynchronous service disconnected from the job submitter as soon as the necessary resources are available. The first program unit reads the data with FGET and terminates with PEND SP. A synchronization point is set and the follow-up program specified in KCRN is started.
The TAC1 program has not transferred an MPUT to the TAC2 program. However information can be forwarded in the service-specific storage areas. The TAC2 program selects an MPUT call for the transfer of information to TAC3 and terminates with PEND PA. This means that no synchronization point is set. In the TAC3 program the service is terminated with PEND FI.
Asynchronous services which also issue jobs
An asynchronous service may in its turn create asynchronous jobs. These may be output jobs or further background jobs. In distributed processing, you can also issue dialog jobs to partner applications from an asynchronous service, i.e. the asynchronous service communicates with remote dialog services.
Figure: Asynchronous services which also issue jobs
In the first program unit of the TAC 1 asynchronous service, a job is issued to the TAC2 asynchronous service. To do this, you have to specify the TAC2 transaction code in the KCRN field when you call FPUT. Since the program unit terminates at a synchronization point, the job is already inserted in the relevant queue at the end of the program unit.
An asynchronous job is also issued in the TAC2 service of the first program unit. This is an output job to the printer. You have to specify the LTERM name of the printer in the KCRN field when you call FPUT. Since this program unit does not terminate at a synchronization point the job is inserted into the LTERM queue at the end of the service (next synchronization point).
The TAC 2 service is divided into two processing steps. The first program unit uses MPUT to send a message to a remote dialog service. The second program unit is started when the response is received from the remote service. This is read using MGET.
Job complexes
Together with the asynchronous job ("basic job") you can describe up to two more confirmation jobs which are associated with the positive or negative result of job processing. These confirmation jobs are processed after the basic job is processed. The job submitter can use the confirmation jobs to react to a positive or negative job result. A confirmation job which is not used, e.g. a negative confirmation job for a positive result, is deleted. The entity formed by a basic job and its associated confirmation jobs is called a job complex.
The following table shows some of the possible events which may occur during asynchronous processing and the effects of these events on the confirmation jobs.
The beginning and the end of a job complex are defined by means of separate KDCS calls, the MCOM BC (begin of complex) call and the MCOM EC (end of complex) call. With the MCOM BC call you define the complex identifier (complex ID), the destination of the asynchronous job and the TACs of the asynchronous programs which are to process the positive or negative confirmation. All the jobs generated within the complex are described using DPUT calls. You must specify the complex ID as the target.
A job complex can be defined both in dialog and in asynchronous programs.
If the basic job of an job complex is addressed to a remote asynchronous service, then the service identifier must be assigned (via APRO AM) before the beginning of the job complex. With MCOM BC you define the service ID in KCRN; the confirmation jobs have to be processed by the local application.
Event | Effect on confirmation job |
|---|---|
PEND FI in the local asynchronous service | Start of positive confirmation job and deletion of negative confirmation job |
For background job, successful transfer to asynchronous service | |
Positive print confirmation from printer or print administration | |
Processing a message of a TAC queue and termination of the transaction | |
PEND ER/FR in local asynchronous service without redelivery | Start of negative confirmation job and deletion of positive confirmation job |
Error while preparing the output message by VTSU-B on BS2000 systems | |
Error while formatting the output message on BS2000 systems | |
Processing a message of a TAC queue and rollback of the transaction without redelivery | |
For background job to asynchronous service, rejection of the job | |
Deletion of a job by administration | |
Delete the output job when establishing or clearing down the connection of a RESTART=NO client. | |
PEND ER/FR in the local asynchronous service with redelivery | Without effect, since basic job is still present |
Negative print confirmation from printer or timeout waiting for a confirmation | |
Sequence of jobs changed by administration | |
Repetition of a print job | |
Processing a message of a TAC queue and rollback of the transaction with redelivery | |
Deletion of a job with confirmation jobs by print administration | Confirmation jobs are deleted; logged in SYSLOG |
KDCUPD does not accept a job | Confirmation jobs are also not accepted (see KDCUPD log) |
The following diagram illustrates a job complex, taking a print job as an example.
Figure: Job complex for a print job