Existing UTM program units which were not specifically designed for communication via OSI TP can be used unchanged for OSI TP communication given certain restrictions (see below). The same service can, for example, be used by clients as well as other services. In this way openUTM gives you considerable flexibility when distributing applications.
The various cases which may arise when using existing program units for OSI TP communication are identified and described in the following sections.
Program units for communication with clients as OSI TP job receiver
Program units which have been designed for communication with clients can be used unchanged by the job receiver for communication with an OSI TP partner. You must observe the following points:
Different return information in KB header
The communication partner of the job-receiving service is the job-submitting service, not the user at the terminal. This is why the job-receiving service does not receive the name of the LTERM partner in the KB header. Instead, it receives the name of the OSI-LPAP partner. The entry in the KCBENID/kcuserid field depends on the security type used. You use the APRO call to select the security type in the job submitter (in the KCSECTYP field):
With security type "N" (None), no user ID is transferred to the job receiver. KCBENID/kcuserid contains the name of the association instead of the user ID.
With security type "P" (Program), KCBENID/kcuserid contains the user ID which was specified through APRO in the job submitter.
With security type "S" (Same), KCBENID/kcuserid contains the user ID under which the job submitter was started.
Different TLS and ULS assignments
Write and read calls for TLS in the job-receiving service refer to the TLS of the OSI-LPAP partner and not to a TLS of an LTERM partner. Similarly, calls for a ULS refer to the ULS of the user ID only if security type P/S is present. If security type N is present it refers to the ULS of the association.
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 MGET is used, the job-receiving service can therefore never receive the corresponding KDCS return code (19Z to 39Z).
The card reader cannot be used in the job-receiving service.
In a job-receiving service, the KCAUSWEIS/kccard field always contains blanks.
Abstract syntax for distributed processing via OSI TP
In distributed processing via OSI TP, the format identifier is used to transfer the name of the abstract syntax.
Job receiver programs designed for communication with clients can only be used unchanged for distributed processing via OSI TP if you use UDT Octet String Mapping exclusively as the abstract syntax. Using any other abstract syntax you would have to perform adaptations for the encoding or decoding of messages. The KCMF/kcfn field must therefore always contain blanks.
LU6.1 job receiver as OSI TP job receiver
Job receiver program units written for communication via LU6.1 can only be used unchanged as OSI TP job receivers when the commit functional unit has not been selected and the when the following conditions are fulfilled:
You use UDT Octet String Mapping exclusively as abstract syntax for communication via OSI TP. The KCMF/kcfn field must therefore always contain blanks when exchanging messages.
The transaction and service status in the job receiver programs are not evaluated.
If the commit functional unit is selected, then the job submitter must be the first to request the end of the transaction and the end of the service, and must also always issue the request when the job receiver expects it.
LU6.1 job submitter as OSI TP job submitter
Job submitter program units written for communication via LU6.1 cannot be used as OSI TP job submitters unchanged. At the very minimum, you will have to adapt the APRO call (selection of OSI function in KCOF field and possible changes in the 2nd parameter area). No adaptations are necessary for distributed processing without global transaction management (Cooperative Processing).
In distributed processing with global transaction management, i.e. when the functional unit commit is selected, the programs must always be extended to take account of end-of-dialog requests (e.g. by inserting CTRL PE).