UPIC clients and TS applications are clients that were generated with partner type UPIC-R, APPLI or SOCKET, and in case of partner type SOCKET communicate via UTM Socket Protocol (USP).
The connection is set up by the client in the case of UPIC clients, and by the client or openUTM in the case of TS applications; connection setup by openUTM is only possible if the TS application is generated explicitly with a PTERM statement.
If the client sets up the connection, the client must know the name or, in the case of partner type SOCKET, the port number of the UTM application as well as the host name and/or host address.
When a connection is set up successfully, a UPIC client or TS application signs on in two stages:
Implicit sign-on using a connection user ID
A connection user ID is strictly assigned to an LTERM partner of a TS application or a UPIC client and is created explicitly or implicitly at UTM generation:
Explicit creation by USER= specification in the LTERM statement.
Additional characteristics can be defined with the KDCDEF statement USER for connection user IDs defined in this way.Implicit creation by openUTM if no USER was specified in the LTERM statement or if an LTERM pool is used (TPOOL statement). The LTERM name is then used as the name of the connection user ID; in the case of an LTERM pool, the LTERM name is made up of the generated prefix and a serial number, e.g. UPIC0025. For LTERM pools, special key codes can be assigned to the connection user ID with TPOOL ...USER-KSET=. The access options of the connection user ID can thus be restricted.
If no sign-on attempt is made under a real user ID, the preliminary sign-on of the connection user ID becomes permanent. This is recorded with a message. In the case of UPIC clients, this message is also output if the client subsequently signs on under a real user ID.
Explicit sign-on using a
real user ID (optional)
UPIC clients and TS applications behave differently in this case:
In the case of UPIC clients, the user ID and sign-on data must be set in the respective UPIC interface calls. UPIC then transfers these values to openUTM, which then performs the sign-on for the transferred user ID. This replaces the connection user ID for the duration of the conversation.
At the end of the conversation, the user is signed off again if the UTM application is generated with SIGNON OMIT-UPIC-SIGNOFF=NO.
If the UTM application is generated with SIGNON OMIT-UPIC-SIGNOFF=YES, the user remains signed on after the end of the conversation and is only signed off,if another user ID is passed in the UPIC protocol before a new UPIC conversation is started over the same UPIC connection,
or when the connection is cleared.
If the UPIC client does not transfer any sign-on data in the UPIC interface calls, signing on using a real user ID is only possible with a corresponding sign-on service; see "Sign-on process with sign-on services".
A user can only sign-on under a real user ID via a transport system connection if an appropriate sign-on service is generated for the application; see "Sign-on process with sign-on services". It is not possible to sign on with a real user ID using the standard sign-on dialog.
If a TS application signed on using a real user ID, this user ID replaces the connection user ID for the full duration of the connection.
In the case of both UPIC clients and TS applications, the connection user ID remains signed on for at least as long as the real user ID. If the connection is lost, a renewed connection setup attempt may be rejected if a program is still running under the real user ID and the connection user ID is thus also considered to be signed on. In this case, the user must wait until the program terminates before signing on again.