Provided that certain conditions are satisfied, you can use UTM program units, which were designed to communicate with terminals, unchanged as program units in a job-receiving service (see list below). Existing asynchronous programs can also be used as job receivers without any adaptations.
The same service can thus be used by terminals and client programs as well as by other services. In this way openUTM gives you considerable flexibility in application distribution.
If you want to use existing program units as job-receiving program units unchanged, or want to develop program units which can be used by terminals and client programs as well as by other services, you have to take account of the following points:
Different return information in KB header
The communication partner of the job-receiving service is not the user at the terminal, but the job-submitting service. This is why the job-receiving service receives neither the ID of the terminal user nor the name of the LTERM partner in the KB header. (It is possible that neither are even generated in the application of the job-receiving service). Instead it receives the local session name (LSES name) and the local name of the partner application (LPAP name).
Different assignments of TLS and ULS
Write and read calls for TLS in the job-receiving service refer to the TLS of the LPAP partner and not to a TLS of an LTERM partner. Similarly, calls for a ULS refer to the ULS of the session.
Function keys are not supported in distributed processing
The job-submitting service cannot send a message corresponding to the function key to the job-receiving service. When using MGET the job-receiving service can therefore never receive the corresponding KDCS return code (19Z to 39Z).
The card reader is not supported in distributed processing.
In a job-receiving service, the KCAUSWEIS/kccard field always contains blanks.
No formatting in distributed processing via LU6.1
It is usually unimportant to a service whether it receives the dialog message from a terminal, an openUTM client program or from an LU6.1 partner. In the case of distributed processing via LU6.1, openUTM transfers the format ID specified in the job-submitting service with the MPUT call, but does not perform any formatting. The format identifier is also transferred with all message segments.
If you specify an incorrect format identifier in MGET, then openUTM operates when distributed processing via LU6.1 is used just like it does when segment formats are used for terminals: openUTM acknowledges an incorrect format identifier in MGET with the KDCS return code 03Z, and no messages or message segments are passed in the message area.
Special structure of the job-submitting service (with distributed dialogs)
If existing program units of an application are to be used as program units in a job-receiving service, or if the job-receiving programs are programmed in such a way that they cannot evaluate the status indicators in the MGET call, the job-submitting service has to let itself be controlled by the job-receiving service with regard to transaction management. This means the bottom up strategy (see "Programming rules and recommendations") must be observed. To ensure this the job-submitting service must take account of the transaction status of the job-receiving service: end of transaction (PEND RE/SP) may not be set in the job submitter until all job receivers have transaction status "P".