To enable you to add objects dynamically to the configuration of your UTM application, you must make the following preparations when generating the application with KDCDEF.
No preparations are required for deleting objects from the configuration during KDCDEF generation.
Reserving spaces in the object tables of the KDCFILE
The configuration data of a UTM application is stored in the object tables of the KDCFILE that is created during KDCDEF generation of the application. During KDCDEF generation, the space required to accommodate these tables is also defined. For this reason, during KDCDEF generation, you must reserve table spaces for any objects which you wish to add to the configuration of your application at runtime. You are assisted in this process by the KDCDEF statement RESERVE (see the openUTM manual “Generating Applications”).
In the RESERVE statement you indicate how many table spaces are to be set aside for each single type of object, i.e. how many LTERM partners are to be created dynamically, how many transaction codes etc. Table spaces are reserved individually for each object type, i.e. a table space which you have reserved for an LTERM partner cannot be occupied by a transaction code etc.
During the application run, you can dynamically create as many objects of one type as you have reserved table spaces with KDCDEF. Deleting another object of the same type does not free up a table space for a new object. An exception to this are user IDs and connections for distributed processing by means of LU6.1 for stand-alone applications. These you can delete from the configuration immediately (see section "Deleting objects dynamically from the configuration"). The table spaces occupied by these user IDs or LU6.1 connections are then freed up immediately and are thus available for new user IDs and LU6.1 connections.
When reserving table spaces with RESERVE, always consider the following points:
openUTM internally creates one user ID for each UPIC and for each TS application (client of type APPLI or SOCKET) which you add dynamically to the configuration. In UTM applications generated with user IDs (i.e. where KDCDEF generation contains at least one USER statement), an additional table space is reserved for user IDs for every APPLI, SOCKET or UPIC type client created dynamically. These table spaces are not freed up, when clients are deleted. In applications with no user IDs, these table spaces are reserved by openUTM internally.
For further information about reserving table spaces, see the openUTM manual “Generating Applications”, RESERVE control statement.
Generating lock codes, BCAMAPPL names and the formatting system
In the KDCDEF run you must have already generated objects or values statically in advance if you want to reference them later in dynamic configuration; examples of this are the value range of lock codes and the names of the transport system access points of the local application.
Lock codes (access protection) which you wish to assign to the transaction codes and LTERM partners must fall in the range between 1 and the maximum value defined in KEYVALUE (MAX statement). For this reason, you should select a sufficiently high number for KEYVALUE and also generate keysets containing the appropriate keycodes (see notes on the lock/keycode concept in the openUTM manual “Concepts und Functions”).
All names in the local application (BCAMAPPL names) which are to be set up using connections to clients or printers must be generated using KDCDEF. In particular, remember that you have to generate special BCAMAPPL names in order to link TS applications via the socket interface or HTTP clients (PTYPE=SOCKET).
Only on BS2000 systems: If start formats are to be assigned to user IDs and LTERM partners, a formatting system must be generated during KDCDEF generation (FORMSYS statement). If #formats are used as start formats, an additional sign-on service must be generated.
Requirements for adding program units and VORGANG exits
You can only add new program units and VORGANG exits to the configuration of your application dynamically if the application satisfies the following requirements:
UTM applications on BS2000 systems must be generated with load modules (KDCDEF generation with LOAD MODULE statements).However, the program unit should not be linked to a load module which is linked statically to the application program (STATIC load mode)
UTM applications on Unix or Linux systems must be generated with shared objects (KDCDEF generation with SHARED-OBJECTS statements).
UTM applications on Windows systems must use Windows DLLs. You will find further details on how to generate the application in the openUTM manual “Generating Applications”.
A program unit which you wish to create dynamically at runtime must be linked to a load module, shared object or a DLL which was defined during KDCDEF generation.
At least one program unit must have been generated with KDCDEF for each programming language in which you wish to create program units in your application. Only then does the application program contain the language link modules and runtime systems it requires in order to run.
Note for BS2000 systems:
In the case of program units compiled with ILCS-capable compilers (COMP=ILCS), it is sufficient to generate a program unit with COMP=ILCS during KDCDEF generation. No PROGRAM statements have to be submitted for the various programming languages.
In the case of COBOL programs, the relevant LOAD-MODULE must be generated with ALTERNATE-LIBRARIES=YES in order to allow the required RTS modules to be dynamically loaded by autolink.
Requirements for the dynamic creation of transaction codes
If you wish to add transaction codes dynamically to the configuration, you must take account of the following points:
Transaction codes for program units which use an X/Open program interface can only be created dynamically if at least one transaction code for an X/Open program unit was generated statically with KDCDEF (TAC statement with API
!=KDCS).If you wish to divide the transaction codes into TAC classes, in order to be able to control job processing, then you must create at least one TAC class during KDCDEF generation.
During KDCDEF generation you can create TAC classes in three ways:
Generate a transaction code for which you specify a TAC class in the TACCLASS operand (TAC statement). KDCDEF will then implicitly generate the specified TAC class.
If you are running the application without priority control (it contains no TAC-PRIORITIES statement), you can generate TAC classes by writing a TACCLASS statement.
You can create TAC classes implicitly by writing a TAC-PRORITIES statement.
Once you have created a TAC class during KDCDEF generation you can assign the transaction codes which you create dynamically to any TAC class of your choice between 1 and 8 (dialog) or 9 and 16 (asynchronous). The TAC classes are created by openUTM implicitly. These implicitly created TAC classes can be administered.
If you generated the application without TAC-PRIORITIES, openUTM specifies the number of processes (TASKS) in implicitly generated TAC classes as follows:
1 for dialog TAC classes (classes 1 to 8),
and 0 for asynchronous TAC classes (classes 9 to 16).However, openUTM only creates asynchronous TAC classes if you set ASYNTASKS > 0 in the MAX statement during KDCDEF generation.
In applications containing TAC classes without priority control, you can only create transaction codes dynamically which start program unit procedures with blocking calls if TAC classes with PGWT=YES (dialog and/or asynchronous TAC class) were explicitly created with TACCLASS statements in KDCDEF generation and MAX TASKS-IN-PGWT > 0.
In applications with priority control (with TAC-PRIORITIES statement), you can only create transaction codes dynamically which start program unit procedures with blocking calls (kc_tac_str.pgwt='Y') if MAX TASKS-IN-PGWT>0 was specified during KDCDEF generation.
Requirements for the dynamic creation of user IDs
You can only add user IDs to the configuration dynamically if your application was generated with user IDs. For this, your KDCDEF generation must contain at least one USER statement and at least one user ID must have administration privileges (USER with PERMIT=ADMIN).
Note for BS2000 systems:
If new user IDs with ID cards are also to be added to the configuration at runtime then, when reserving table spaces with the RESERVE statement, you must explicitly indicate what percentage of user ID table spaces is to be set aside for user IDs with ID cards (CARDS operand in the RESERVE statement).
If user IDs with Kerberos authentication are to be dynamically generated during operation, they must be reserved using the PRINCIPALS operand of the RESERVE statement.