SIGNON - control the sign-on procedure

You can specify options and parameters for the sign-on procedure of your UTM application with the SIGNON control statement. The signing on of users is controlled by the SIGNON parameter.

The parameters UPIC, RESTRICTED and CONCURRENT-TERMINAL-SIGNON are only relevant if a sign-on service is generated.

If you enter an invalid value for the SIGNON operand, then KDCDEF uses the corresponding default value. This is currently done without outputting a corresponding message (see the following descriptions of the operands).

SIGNON

[ CONCURRENT-TERMINAL-SIGNON=%_value ]   [ ,GRACE={ NO | YES } ]  [ ,MULTI-SIGNON={ YES | NO } ]  [ ,OMIT-UPIC-SIGNOFF={ YES | NO } ]  [ ,PW-HISTORY=number ]   [ ,RESTRICTED={ YES | NO } ]  [ ,SILENT-ALARM=number1 ]   [ ,UPIC={ YES | NO } ]

CONCURRENT-TERMINAL-SIGNON=%_value  

This is only relevant when your application is generated with a sign-on service.

You specify the percentage of users generated for which a sign-on service may be active at the same time in CONCURRENT-TERMINAL-SIGNON. openUTM attempts to allocate the necessary resources according to this specification.

The value %_value is based only on sign-on services that are started for terminal users and TS applications.

Default: 25 (%)
Minimum value: 1 (%)
Maximum value: 100 (%)

If you enter a value < 1 or > 100 for %_value, KDCDEF sets the default value of 25 % without outputting a message.

GRACE=

(Grace-Sign-On)
Specifies if a user may still change his or her password after the password validity period has expired (see USER PROTECT-PW, "USER - define a user ID").

    YES

The user can still change his or her password after the password validity period has expired.
The change must be made within the sign-on procedure, before the user is completely signed on.
If a sign-on service is activated, the password can be changed there using the KDCS call SIGN CP, regardless of the client type. A sign-on service is always activated when a user signs on via a connection for whose transport access point a sign-on service has been generated.

The table below shows how the individual client types behave when a password has expired and how this behavior depends on whether a sign-on service is activated.

Client type	Behavior if the password has expired 1)
UPIC	Regardless of whether a sign-on service is activated, the password can be changed using the Set_Conversation_Security_New_Password function.
BS2000 terminal	If the password is blanked out, openUTM prompts the user to change the password, regardless of whether a sign-on service is activated.
	If the password is not blanked out, openUTM prompts the user to change the password only if no sign-on service is activated.
Terminal on Unix, Linux and Windows systems	openUTM prompts the user to change the password, regardless of whether a sign-on service is activated.
TS application	The user can no longer change the password without activation of a sign-on service.
HTTP client	The user can not change the password.

¹⁾ The password can always be changed via the administration interface. By default, passwords with limited periods of validity are immediately set to "expired" when changes are made via the administration interface. If you want to prevent this, then you must explicitly request this in the administration interface.

Note the following particularities after regeneration or change generation:

• If, after regeneration (followed by a KDCUPD run), the password of a user becomes invalid because the complexity requirement has been increased, the user can change his or her password in the sign-on service only (using SIGN CP).

• After regeneration (without a subsequent KDCUPD run), openUTM forces users to change passwords generated with a validity period when they first sign on.

    NO

The user cannot change his or her password after the validity period has expired. The password may only be changed by an administrator after the validity period has expired.

Default: NO

MULTI-SIGNON=

Specifies if a user may be signed on to the application multiple times under the same user ID simultaneously.

The MULTI-SIGNON operand does not have any effect on the receiving and starting of asynchronous services via OSI TP.

    YES

The following cases can arise:

• The user ID is generated with USER..,RESTART=NO:
  In this case the user may sign on to the application a multiple number of times simultaneously. However, the user may only sign on once through an application. The user can also sign on via UPIC, APPLI, SOCKET and OSI TP connections.

• The user ID is generated with USER...,RESTART=YES:
  In this case the user may sign on no more than once to the application, although additional job-receiving services can be active in the application for the user if these services are started via OSI TP connections and the commit functional unit was selected.

    NO

Every user ID may only be signed on once, and no more than one dialog service can be active at a time for each user.

Default: YES

OMIT-UPIC-SIGNOFF=  

Specifies whether a user who has signed on over a UPIC connection remains signed on or not after the conversation has finished.

    YES

If a user has signed on over a UPIC connection, they remain signed on after the conversation has finished. This user is only signed off

• if another user is passed in the UPIC protocol before a new UPIC conversation is started over the same UPIC connection,

• or when the connection is cleared.

If no other user is passed in the UPIC protocol, no sign-on service is started before the UPIC conversation is started.

If the application is generated without users, the user ID is never changed for an existing connection. In this case, therefore, a sign-on service is only started where necessary before the first conversation is started after the connection has been established.

Default in UTM cluster applications.

    NO

If a user has signed on over a UPIC connection, they are signed off after the conversation has finished.

Default in standalone applications.

PW-HISTORY=

number

Specifies if and how many password changes are to be maintained by openUTM in the password history.

If you enter a value > 0 for number, then openUTM maintains a password history. number is the number of passwords for a user ID that are recorded by openUTM.

If a user changes his or her password and if a maximum period of validity is generated for the password in the USER statement, then the new password must be different from the current password and the last number of passwords used by the user. number=0 means that openUTM will not maintain a password history.

Default: 0
Minimum value: 0
Maximum value: 10

If you specify a value > 10 for PW-HISTORY, then KDCDEF sets it to the maximum value of 10.

The password history only applies to the user; the administrator can change the password irrespective of the history.

RESTRICTED=

Specifies if DB calls and access to global UTM storage is prohibited in the first part of the sign-on service.

    YES

DB calls and access to global UTM storage is prohibited in the first part of the sign-on service.

    NO

DB calls and access to global UTM storage is permitted in the first part of the sign-on service.

Default: YES

SILENT-ALARM=

number1

Specifies the number of unsuccessful sign on attempts that may occur one after the other via an LTERM partner or a terminal user. A silent alarm (message K094) is triggered when this number is exceeded. The message is output after number1 unsuccessful sign-on attempts in a row by a user or by a client.

Default:  10
Minimum value: 1
Maximum value: 100

UPIC=

This is only relevant when a sign-on service is generated in your application.
With UPIC= you specify in UPIC if the sign-on service is activated when a UPIC client wants to start a conversation.

    YES

If a sign-on service is generated for the transport system end point (BCAMAPPL) via which the UPIC client has connected to the application, this is started before every UPIC conversation.

    NO

No sign-on service is started for UPIC clients.

Default: NO