A distinction is drawn between two possible scenarios when signing on using a sign-on service:
The UPIC client transfers authorization data to openUTM in the UPIC protocol. If openUTM accepts the data, the sign-on service is started under the transferred real user ID and the client is signed on under this user ID, provided the sign-on service is completed successfully.
If the UPIC client does not transfer any authorization data in the UPIC protocol, the signon service is started under the connection user ID. The authorization data of a real user ID can be passed in the sign-on service. If openUTM accepts the data, then the user is signed on under the specified user ID when the sign-on service ends properly. If no authorization data is passed, then the conversation runs under the connection user ID.
If the sign-on fails under a real user ID, a successful sign-on must follow under a real user ID, as otherwise the conversation is terminated when the sign-on service is terminated. This means that the connection user ID is not a fallback step for a failed sign-on attempt.
To ensure that client programs can be implemented regardless of whether or not the UTM application uses a sign-on service, messages from the client that were not read in the signon service can be read in the subsequent program unit after terminating a program unit of the sign-on service with PEND PA, PEND PR, PEND PS or PEND FC without preceding MPUT.