Your Browser is not longer supported

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

{{viewport.spaceProperty.prod}}

Deleting objects dynamically from the configuration

You can use the KC_DELETE_OBJECT call at the program interface for administration to delete objects from the configuration of your application while the application is running.

We distinguish two methods for deleting objects: delayed delete and immediate delete.

  • delayed delete (KC_DELETE_OBJECT subopcode1=KC_DELAY)

    The term delayed delete is used to mean that objects are simply designated as deleted. The objects and their properties remain in the object table as before. Delayed deletion acts like a permanent lock which cannot be undone. Physical deletion of objects from the object table only takes place during regeneration if you are working with the inverse KDCDEF.

    Users no longer have access to an object designated for delayed deleting. Only the administrator still has read-only access to such objects, i.e. you can read the names and properties of objects designated for “delayed delete” with KC_GET_OBJECT or with the administration command KDCINF. However, it is no longer possible to change the properties of these objects. User IDs designated for a “delayed delete” can, however, be completely removed from the configuration using an “immediate delete”.

    A delayed delete frees up no space in the object table. The names of deleted objects remain assigned, i.e. no more new objects can be created dynamically in their name class. In particular, no new objects can be created dynamically with the same name and the same object type.

    Key sets, LU6.1 sessions, LTACs, LTERM partners, program units, transaction codes and TAC queues can only be removed from the configuration using the delayed delete method.

  • immediate delete (KC_DELETE_OBJECT subopcode1=KC_IMMEDIATE)

    Immediate deletion is only permitted for the user IDs and LU6.1 connections of standalone UTM applications.

    Immediate delete removes an object and its properties from the object table with immediate effect. The table space assigned to a user ID or CON object removed using the “immediate delete” method is available for a newly created user ID or CON object right away without the application needing to be regenerated. The name of a user ID or CON object that is deleted immediately does not remain locked. You can generate a new user ID or CON object using the same name right away.

    Once an object is deleted in this fashion, nobody, including the administrator, any longer has any kind of access to it, neither read nor write access.

You can delete just one object with each KC_DELETE_OBJECT call (delayed or immediate delete). In any one program unit, you can make several KC_DELETE_OBJECT calls in succession, i.e. you can delete several objects of different types. In the case of objects related to one another, it is nevertheless important to pay attention to the sequence in which these objects are deleted. An object to which other objects are related cannot be deleted until the other related objects have been deleted, i.e. until their relationship has been cancelled by means of administration functions (e.g. KDCSWTCH can be used to terminate the relationship between terminal/printer and LTERM partner). The following sections describe the rules you must observe when deleting objects.

Object deletion, be it delayed or immediate, is subject to transaction management. The object is not deleted until the transaction in which the KC_DELETE-OBJECT is being processed has been completed successfully.

However, only objects that are featured in the configuration can be deleted. In other words, you cannot delete an object created dynamically in the configuration until the transaction in which the create operation took place has been completed.

Deletion in UTM-F and UTM-S applications applies beyond the end of these applications and cannot be undone.

UTM cluster applications (Unix, Linux and Windows systems)

The following applies in UTM cluster applications:
The call applies globally to the cluster, i.e. objects are deleted from the configuration in all the node applications. Only delayed deletion is permitted in UTM cluster applications.