You can remove a user ID from the configuration using either the “delayed” or the “immediate” delete method (see "Deleting objects dynamically from the configuration"). In UTM cluster applications (Unix, Linux and Windows systems) only the delayed delete method is possible.
To delete a user ID from the configuration you must call KC_DELETE_OBJECT (with subopcode1=KC_DELAY or KC_IMMEDIATE) for the object type KC_USER.
Apart from the exceptions listed below, you can delete any user ID created explicitly in the configuration (statically or dynamically).
You cannot delete the following user IDs:
KDCMSGUS, which openUTM creates internally for the MSGTAC service
user IDs assigned to a terminal for an automatic KDCSIGN (see "Adding clients, printers and LTERM partners")
connection user IDs (i.e. user IDs that are permanently assigned to a client of the type UPIC, APPLI or socket)
In applications without explicitly generated user IDs, the deletion of user IDs created internally is generally not possible.
The following restrictions apply with regard to the point in time at which a user ID may be deleted:
You can only delete a user ID (delayed or immediate delete) if no user or client is signed on to the application at the time of deletion. For this reason, you should disable the user ID before deletion to avoid errors. Such disabling operations must occur in a separate transaction. To disable a user ID, see KDCUSER in "KDCUSER - Change user properties" or KC_MODIFY_OBJECT with "obj_type=KC_USER".
Deleting a user ID is also temporarily not possible in the following cases:
an asynchronous job is being processed, i.e. has been retrieved from the message queue and started.
a distributed transaction is in PTC status (PTC = Prepare to Commit).
the user-specific long-term storage area (ULS) of the user ID cannot be locked, e.g. because the administrator or an administration program is accessing it.
Delayed delete
Delayed deletion of a user ID has the following effects:
No users/clients are able to sign on to the application with a user ID designated for a delayed delete.
Asynchronous services which were started before the user ID was deleted and which are not being processed at the time of deletion are still able to run and can be administered. These services are not, however, able to create any more asynchronous jobs themselves.
An open dialog service cannot be continued any further. Any service data that has been saved for a user (e.g. LSSB data, dialog messages) is deleted:
in the case of standalone applications, the next time the application is started
in UTM cluster applications (Unix, Linux and Windows systems), on the next start-up of the node application at which the user was last signed on
The data is not deleted if an open service has a transaction in the PTC state. In this case, the transaction must first either be committed or rolled back. You can, for example, roll back transactions with the PTC state using the program interface (opcode KC_PTC_TA).
ULS areas (ULS = user-specific long-term storage area) belonging to the user ID are still available for read and write accesses.
All the messages in the message queue for this user ID are deleted immediately. No new messages can be created for this message queue.
Immediate delete
Immediate deletion of a user ID has the following effects:
No users/clients are able to sign on to the application with an immediately deleted user ID.
Asynchronous jobs which were generated and placed in the message queue by openUTM before the user ID was deleted, do not start, i.e. openUTM does not process them. They are deleted the moment openUTM retrieved them from the message queue for processing.
If you query the information on jobs in the message queue using DADM RQ (see "Displaying information on messages in a queue - DADM RQ"), openUTM, instead of the user ID that issued the job, will output *NONE for the jobs of a deleted user ID.
Jobs for LTERM or LPAP partners that are started before the user ID is deleted and are still in the partner’s message queue, are sent.
An open dialog service that was started by a deleted user ID, is also deleted immediately. There may be open dialog services for a user who is not signed on, e.g. if the user signed off during the service using KDCOFF after a synchronization point had already been reached.
ULS areas (ULS = user-specific long-term storage area) belonging to the deleted user ID cannot be accessed. They are deleted.
All the messages in the message queue for this user ID are deleted immediately.