You use an APRO AM call to address the job-receiving service. Enter the service ID in the KCPI field.
In the case of distributed processing via OSI TP you can use the APRO call to select whether or not to transfer an asynchronous job with global transaction management. If global transaction management is used, openUTM ensures that the job is transferred precisely once as long as it is not lost during transmission due to a serious error (see "UTM-controlled queues in distributed processing").
In the event of a connection failure, asynchronous jobs without global transaction management are may sometimes be transferred more than once.
After an APRO AM call, the job-submitting service can:
enter a service identification as the destination in KCRN and use FPUT to send an asynchronous job or DPUT to send a time-driven asynchronous job to the corresponding remote service.
use MCOM BC to define the start of a job complex and use DPUT to send an asynchronous job (basic job) to the partner application within the complex and to create the associated positive or negative confirmation jobs. The confirmation jobs are processed by the local application.
use MCOM BC to define the complex ID and enter the service Id in KCRN. For DPUT, you must then enter the complex ID in KCRN.
You must issue an FPUT or DPUT call with this service ID within the program unit which addresses the remote service with APRO AM, otherwise openUTM aborts the service with KCRCCC=86Z and releases the service ID when PEND is called.
The service ID is released in the job-submitting service in the following cases:
after a successful FPUT NE or DPUT NE call
on the next PEND call (also PEND KP and PEND PA/PR)
after a RSET call
after the return code 40Z following an FPUT or DPUT call
in job complexes with this service ID: When calling MCOM EC or after a return code 40Z following MCOM BC or after calling DPUT
Once released, this service ID can be used for another job submitter/job receiver relationship in the job-submitting service.
The job entry in the job submitter is deleted from the message queue as soon as it has been successfully transferred and inserted into the corresponding message queue of the partner application. Depending on the processing result, the positive or negative confirmation job is then started when message complexes are used.