kc_signon_str - Properties of the sign-on process

The data structure kc_signon_str is defined for the object type KC_SIGNON. In the case of KC_GET_OBJECT, UTM returns the values of the parameters through which the communication partner is signed on to the application in kc_signon_str.

Data structure kc_signon_str

char concurrent_terminal_signon[3];

char grace;

char pw_history[2];

char restricted;

char silent_alarm[3];

char upic;

char multi_signon;

char omit_upic_signoff;

The fields of the data structure have the following meanings:

concurrent_terminal_signon
	Only relevant if a sign-on process is generated in your application. concurrent_terminal_signon specifies in percent for how many of the generated users the sign-on process which has been started for a sign-on via a terminal or a TS application (APPLI or SOCKET) can be active at one time. UTM tries to make available the required resources according to this value.
grace	(Grace-Sign-On)
	Specifies whether a user may still change the password when first signing on after the password has expired (see kc_user_str.protect_pw_time ).
	'N'	The user cannot change the password after it has expired. Only the administrator can do this.
	'Y'	The user can still change the password after it has expired. The modification must be made within the sing-on before the user is entirely 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 function Set_Conversation_Security_New_Password.
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.

1)

The password can always be changed via the administration interface (e.g. KC_MODIFY_OBJECT, obj_type=KC_USER). 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.

pw_history
	Specifies for how many password changes per user UTM records a password history. pw_history contains the number of passwords of each user ID which UTM records. If a user changes the password and if a limited validity period is generated for the password in the USER statement, the new password must differ from the current password and from the last n passwords set for that user ID. n is the number in pw_history. pw_history=0 means that UTM does not keep a password history. The password history is only relevant when a password is changed by the user; the administrator can change the password irrespective of the passwords contained in the history.
restricted
	Specifies whether database calls and accessing global UTM Sorage areas are not allowed in the first part of the sign-on.
	'Y'	Database calls and accessing global UTM storage areas are not allowed in the first part of the sign-on.
	'N'	Database calls and accessing global UTM storage areas are allowed in the first part of the sign-on.
silent_alarm
	Specifies after how many unsuccessful attempts of a terminal user to sign on UTM issues a silent alarm. Silent alarm means that UTM issues message K094.  This value can be modified in the signon_fail field in the data structure kc_max_par_str , see "kc_max_par_str - Maximum values for the application (MAX parameters)" .
upic
	Only relevant if an sign-on process was generated in your application. upic specifies whether the sign-on process is activated when an UPIC client wishes to start a conversation.
	'Y'	If a sign-on process is generated for the transport system access point by means of which the UPIC client has set up the connection, this is started before every conversation initiated by the UPIC client.
	'N'	No sign-on process is started for UPIC clients.
multi_signon
	Specifies whether several users can be signed on with the application under the same user ID at the same time.
	'Y'	The following cases must be distinguished: The user ID is generated with RESTART=NO: Several users can be signed on with the application under the same user ID at the same time. However, only one of the users may be signed on at the terminal. The user ID is generated with RESTART=YES: Several job-receiving services can only be active under the same user ID at the same time if the job-receiving services are started via OSI TP connection and the “commit” function is selected.
	'N'	No more than one user can be signed on with each user ID in the application, i.e. no more than one dialog service may be active per user ID and, if a user is signed on with the application, then no job-receiving service can be started for this specific user ID.
	multi_signon has no effect on user sign-on via an OSI TP connection for creating an asynchronous job.
omit_upic_signoff
	Specifies whether or not the user ID under which a UPIC client program has signed on continues to be signed on after a UPIC conversation has finished.
	'Y'	The user ID continues to be signed on after the end of a UPIC conversation. This user is only signed off again if the connection is cleared or if a UPIC client with another user ID wants to sign on via this connection. If the UPIC client does not send another user ID then the original user ID continues to be signed on, i.e. no sign-on service is started before the start of the new UPIC conversation. In the case of applications without a user ID, a sign-on service may, if necessary, be started once after the establishment of the connection and before the start of the first UPIC conversation. Default in UTM cluster applications.
	'N	The user ID with which a UPIC client has signed on is signed off after the end of each UPIC conversation. Default in standalone UTM applications.