The transfer of user data can be controlled using the KDCUPD TRANSFER statement.
Please note that in the case of standalone applications as well as of node updates in UTM cluster applications, the following remarks only apply to UTM-S.
User data always transferred by KDCUPD
KDCUPD always transfers the following data of a KDCFILE, irrespective of the specifications in the TRANSFER control statement:
asynchronous messages in USER queues when the user, generating LTERM, and generating USER also exist in the new KDCFILE
User data which KDCUPD transfers optionally
The TRANSFER control statement allows you to control which of the following data KDCUPD is to transfer to the new KDCFILE or the UTM cluster files:
Dialog services started by a terminal or a TS application of type APPLI.
Dialog services started by a UPIC client.
Dialog services started by a TS application of type SOCKET.
Passwords for the user IDs and - if generated - the validity period remaining, minimum wait time until the next password change, and the password history
Secondary storage area GSSB, TLS, and ULS
Queued output jobs
Queued messages to local asynchronous services and TAC queues as well as open asynchronous services
Queued messages to local partners
Queued messages to remote partners
Queued messages to temporary queues
Current version number of the loadable objects (load objects on BS2000 systems, shared objects on Unix and Linux systems, DLLs on Windows systems)
The locales of users (only on BS2000 systems)
When services are transferred, all service-specific data is transferred:
Local secondary storage area data
Saved dialog messages
Communication areas
Batch stacked services (only for standalone applications)
Data not transferred by KDCUPD
The following is not transferred by KDCUPD:
Objects which have been added with the administration function such as new USERs.
Data belonging to open, distributed services.
KDCUPD does not issue a message that this data was not transferred!Open dialog services of users when the user does not exist in the new KDCFILE.
Open asynchronous services when the user who started the service or the LTERM or (OSI-)LPAP partner from which the asynchronous service was started does not exist in the new KDCFILE.
Queued messages when the destination of the message, the user who generated the message, or the LTERM or (OSI-)LPAP partner from which the asynchronous service was started does not exist in the new KDCFILE.
The TLS or ULS storage areas when the corresponding LTERM, (OSI-)LPAP, the associated USER, or the associated session or association does not exist in the new KDCFILE.
Service stacks in UTM cluster applications.