Your Browser is not longer supported

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

{{viewport.spaceProperty.prod}}

Programming notes

The SIGNON service controls the sign-on procedure by means of a program. The sign-on service is controlled, above all, by the following KDCS calls (see "PEND Terminate program unit" and "SIGN Control sign-on and sign-off, check authorization data, change passwords"):

SIGN ST

Queries the status of the sign-on service. The call also returns the result of the previous SIGN ON.

SIGN ON

Transfers authorization data to openUTM for checking. The call returns only whether the call was syntactically correct, not whether the sign-on was successful.

PEND PS

Terminate program unit so that openUTM can verify the authorization data and insert the intermediate dialog if necessary. The sign-on service then continues in the follow-up program unit.
Not until this call does a provisional sign-on take place provided the data transferred with SIGN ON were correct.

openUTM on BS2000 systems is shipped with an appropriate sample program. The openUTM manual “Using UTM Applications on BS2000 systems” contains a description of this sample program and additional information on the concept behind the sign-on service and typical applications.

Notes

  • In the first part of the sign-on procedure the KCBENID/kcuserid field in the KB header only contains blanks.

  • If the sign-on is not completed successfully before PEND FI is executed, then openUTM clears the connection to the terminal or the TS application, or it ends the UPIC conversation. In this manner, you can handle several unsuccessful attempts to sign on, e.g. because the user is not authorized, in a simple manner using PEND FI after KCRSIGN1 = U.

  • If the sign-on service violates the rules applicable to it, then openUTM aborts the service with PEND ER. The connection to the terminal or to the TS application is cleared, and the connection to the UPIC client remains.

  • If the UTM application is generated without user IDs (i.e. without USERs), the sign-on service can terminate immediately because the sign-on has been successful. The sign-on service receives the corresponding information at the SIGN ST call.However, an application-specific authorization check can also be carried out in the sign-on service (using a database with authorization data, for example).

  • Restrictions in the sign-on service

    • The KDCS calls PEND RE/RS/SP are prohibited.

    • FPUT/DPUT calls and accesses to a ULS are not allowed before the sign-on is successful. Database calls and accesses to GSSBs and TLSs are only allowed before the sign-on is successful if the SIGNON statement explicitly allow this. You should therefore query the sign-on status (returned in KCRSIGN1) with SIGN ST to see if it contains the value A or R before you execute the accesses stated above.

    • You are not allowed to initiate calls for distributed processing.