Your Browser is not longer supported

Please use Google Chrome, Mozilla Firefox or Microsoft Edge to view the page correctly
Loading...

{{viewport.spaceProperty.prod}}

Possible applications for the sign-on service

The sign-on service offers the user a range of practical options, which are outlined below:

  • The sign-on service for terminals can be conducted as a formatted dialog.

  • Start formats can contain current data such as the date, time, a bulletin, etc.

  • In an application with multilingual users, LTERM-specific start formats can be used to output a welcome screen in the respective language. This option is only available for terminals.

  • User-specific start formats are useful for showing information specific to a user group (bulletin, menu, etc.).

  • TS applications can sign on to a UTM application using a sign-on service with a real user ID. They are thus integrated in the system access and data access concept of openUTM.

  • A real name entered by the user can be converted into a user ID which is defined in the UTM generation (USER username).

  • In the case of a global DB/DC authorization concept, a database call can be used in the second part of the sign-on service to retrieve the current authorization profile for this USER from the database and possibly store it in a user-specific long-term storage area (ULS).

  • In the second part, the sign-on service can ask the user to change his or her password, for example because the system is monitoring the time span in which the user may use the same password.

  • Statistics can be produced on all attempted and successful sign-ons.

  • The FHS format handling system offers the option for terminals of loading the P keys using a global attribute of a #format. In the second part of the sign-on service, for example, the P keys can be loaded user-specifically.

  • The sign-on service can also provide the user with useful information in the case of a subsequent service restart. Such information includes bulletins, maps of keyboard layout, or a display of the service restart. This requires an additional dialog step.

  • If openUTM starts the sign-on service following a SIGN OB call (= KDCOFF BUT by program), it may be advisable to read the last input from the terminal with MGET if new authorization data was already entered there.