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 sign-on 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 sign-on 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.