Using the KC_CREATE_OBJECT call you can add new objects to the configuration of your application during an application run.
| KC_CREATE_OBJECT in "KC_CREATE_OBJECT - Add objects to the configuration" |
You can create exactly one object per KC_CREATE_OBJECT call. However, within the administration program, you can call KC_CREATE_OBJECT several times in order to create several objects. When you place a call, you indicate the type of object, its name and the properties you wish the object to have.
The creation of objects is subject to transaction management. Configuration data is not written to the object table until the transaction has been logged successfully. This means that an object created in a program unit cannot be accessed until the transaction has been concluded successfully. The object cannot be used before this happens and it is also not possible to read or modify the object’s properties. Calls such as KC_MODIFY_OBJECT or KC_GET_OBJECT can be submitted for the new object only after successful completion of the new create operation, i.e. after successful completion of the transaction.
During the transaction in which an object is created, access to this object is only permitted in order to establish a relational link to another object created in the same transaction. For example, a relationship of this kind can be established between a client or printer and its connection point, the LTERM partner, between a transaction code and the related program unit, between a transaction code and its VORGANG exit, or between a key set and the objects (such as LTERMs, USERs, TACs or LTACs) to which it refers.
If two objects which relate to one another are created in one transaction, you must pay careful attention to the order in which the objects were created. For example, you can create a client together with its connection point (LTERM partner) in one and the same transaction. However, the LTERM partner must be created before the client since the name of the LTERM partner is indicated when the client is created.
As a general rule, all objects to which you refer when creating a new object must either already feature in the configuration or have been created in the same transaction prior to the new object. The following section provides a detailed description of each type of object showing the sequence in which the objects must be created.
UTM cluster applications (Unix, Linux and Windows systems)
The following applies in UTM cluster applications:
The call applies globally to the cluster, i.e. the objects are dynamically entered in the configuration in all the node applications.
Availability of dynamically created objects
Dynamically created objects are a component of the configuration, even in subsequent application runs, unless they were deleted with KC_DELETE_OBJECT. The same applies to objects in a UTM-S and a UTM-F application.