The sign-on service for terminals consists of two parts:
1st part: | Read authorization from terminal and transfer to openUTM. |
2nd part: | Send confirmation (message and USER-specific start format for the terminal, for example) in the event of a correct sign-on. |
Between the first and the second part, openUTM may conduct an intermediate dialog with the terminal in order to query further authorization data such as identification information or the password.
openUTM returns the status of the sign-on procedure in the KCRSIGN1 field for SIGN ST. The program unit decides on how to proceed after this point based on this status indicator. The following values are possible:
KCRSIGN1 = C (connected)
The terminal is connected to the application, but there is no user signed on yet.The user on the terminal is requested to enter his or her authorization data via an MPUT call. The program unit terminates itself with PEND KP. The follow-up program unit reads the authorization data with MGET, passes the data with SIGN ON to openUTM and terminates itself with PEND PS.KCRSIGN1 = I (incomplete)
openUTM already knows the user ID, but still requires additional information (password, ID card). This information is queried in an intermediate dialog. The program unit must terminate itself with PEND PS (specify the follow-up TAC!), and then openUTM executes the intermediate dialog.KCRSIGN1 = A (accepted)
The sign-on is correct. The user ID is entered in the KB header. If so desired, additional dialog steps can be inserted before the end of the service. The sign-on service is terminated with PEND FI or PEND FC. The final message is created by the service itself and is output using MPUT. If the message is directed to a terminal, then it can be created from the user-specific start format. The name of the start format is returned by openUTM when SIGN ST is called in the KCRMF/kcrfn field.
When MPUT PM is called, and then PEND FI, the last dialog message of the last service is output, if such a message is available.KCRSIGN1 = R (restart)
The sign-on is correct and a service restart is pending. The user ID is entered in the KB header.
If desired, additional dialog steps can be inserted before the end of the service. The sign-on service must terminate itself with PEND FI. The service restart is initiated by calling MPUT PM, KCLM=0, KCMF/kcfn=blanks. In this case, openUTM outputs the last saved message of the interrupted service (screen restart on the terminal), or it starts the follow-up program unit or follow-up service when there is a local synchronization point after PEND SP/FC. The service that is open can be terminated abnormally by terminating it without using an MPUT call. A K017 message is sent to a TS or terminal partner.KCRSIGN1 = U (unsuccessful)
openUTM did not accept the authorization data. A terminal sign-on service is still in the 1st part and must request the user to re-enter the authorization data. If the sign-on service terminates in this state, the connection to the terminal is cleared.
LTERM partner with automatic KDCSIGN
At the SIGN ST call, the sign-on service receives the information that the user ID is already known. Depending on the generation, an intermediate dialog can be conducted to request a magnetic strip card or a password.
Sign-on via multiplex connection (BS2000 systems)
Depending on the configuration of the multiplex connection in OMNIS, OMNIS forwards the authorization data to openUTM by means of the PUTMMUX protocol for checking. If the data is correct, openUTM starts the sign-on service, which receives corresponding information with the SIGN ST call. If the data is not correct, the sign-on service is not started and the router must inform the terminal at the terminal.
The following diagram shows the sequence of execution of a sign-on service at the terminal:
Figure: Processing of a sign-on service for terminals