If the user ID was generated at KDCDEF generation with RESTART=NO and the UTM application with default value MULTI-SIGNON=YES, a user can be signed on to the UTM application via different connections – though only once via a connection to a terminal. Multiple sign-ons are only possible for real user IDs, not for connection user IDs. More details on connection user IDs can be found on "Sign-on process for UPIC clients and TS applications".
If a user signs on under a user ID generated with RESTART=YES via an HTTP client or an OSI TP partner with the functional unit “commit” selected for its conversation, a further sign-on is possible under this user ID because openUTM does not restart the service in this case and the user ID thus behaves as though no restart was generated.
The same applies if the user signs on via an OSI TP partner and executes an asynchronous request.
Otherwise, a user can only be signed on once at any one time under a user ID generated with RESTART=YES, because the resources needed to restart the service are assigned to the user ID.
Preventing multiple sign-ons for user IDs with RESTART=NO
The MULTI-SIGNON parameter of the SIGNON statement can be used at UTM generation to define that a user can only be signed on to openUTM once at any one time regardless of the restart attribute.
However, this definition does not apply to sign-ons via an OSI TP partner for the execution of asynchronous requests.