Here an asynchronous job for a partner application is handled as if it had been created by a service in your own application. Asynchronous jobs from services in the local application and asynchronous jobs issued by remote services are located in a shared message queue assigned to the asynchronous TAC. An asynchronous service is started for each job in turn, as resources become available. The asynchronous service uses the entry in the KCTERMN field of the KB header to identify whether or not the job submitter is a remote service.
Asynchronous services for remote queuing are structured in exactly the same way as for local queuing (see "Structure of an asynchronous service"). However, in distributed processing via OSI TP another possibility exists: asynchronous jobs to dialog services.
Asynchronous jobs to remote dialog services (only via OSI TP)
When using the OSI TP protocol for an asynchronous job for which APRO was used to specify global transaction management, the job receiver may be a dialog service.
After receipt of an asynchronous job for a dialog service, the service is immediately started in the partner application rather than being inserted into a message queue like a job to an asynchronous service. In the application of the job submitter, the job is not deleted from the message queue until the dialog service is terminated. Depending on the processing result, the positive or negative confirmation job is then started when message complexes are used.
A dialog service which is started by an asynchronous job must use PEND FI to terminate the transaction and may not contain an MPUT to the job submitter (KCENDTA=F and KCSEND=N).