This section describes what objects you must generate statically beforehand and what prerequisites must be met before you can dynamically enter program units, VORGANG exits, transaction codes, user IDs and LU6.1 connections.
Note that the statically generated limit values also apply for dynamically generated objects, e.g. the value defined with MAX ...,KEYVALUE= applies to dynamically generated key sets.
Generating lock codes, BCAMAPPL names, formatting system and LPAP partners
The following objects must be statically generated in KDCDEF:
The lock codes you want to assign to transaction codes and LTERM partners as data access control must lie within the range between 1 and the maximum value defined with MAX,...KEYVALUE= number. At the same time, you must generate the key sets that contain the key codes corresponding to the lock codes.
The lock/key code concept is described in detail in the openUTM manual “Concepts und Functions”.
All names of the local application (BCAMAPPL names) via which the connections are to be established to clients or printers, must be generated with KDCDEF. Remember especially that a separate BCAMAPPL name must be generated for the connection of TS applications via the socket interface (PTYPE=SOCKET).
If start formats are to be assigned to user IDs and LTERM partners, a format handling system must be generated with the FORMSYS statement in the KDCDEF generation. If #formats are used as start formats, a sign-on service must also be generated.
If you want to enter LU6.1 connections or session names dynamically, the LPAP partners and the session characteristics (SESCHA statement) must be statically generated.
Prerequisites for program units and VORGANG exits
New program units and VORGANG exits can only be incorporated dynamically into the configuration of the application if the UTM application
BS2000 systems:
The application was generated with load modules (KDCDEF generation with LOAD-MODULE statements), and the functionality of the BLS must be used for linking and loading the application program.
The new program unit must be linked in a load module which was defined in the KDCDEF generation. This load module must not be linked statically in the application program (LOAD-MODE=STATIC), because this type of load module cannot be exchanged dynamically.
Unix , Linux and Windows systems:
The application was generated with shared objects or DLLs (KDCDEF generation with SHARED-OBJECT statements).
The new program unit must be linked in a shared object or DLL which was defined in the KDCDEF generation.
At least one program unit must be generated statically with KDCDEF for each programming language in which you want to create program units of your application. Only then the language connection modules and runtime systems are required for operation contained in the application program.
For program units compiled with ILCS-capable compilers (COMP=ILCS), it is sufficient to generate one program unit with COMP=ILCS in the KDCDEF generation. It is not necessary to issue PROGRAM statements for the various programming languages.
Prerequisites for transaction codes
Please note the following for the dynamic configuration of transaction codes:
Transaction codes for program units that use an X/Open program interface can only be created dynamically if at least one transaction code has been configured for an X/Open program unit in the KDCDEF generation (TAC statement with API
!=KDCS).If you want to divide the transaction codes into TAC classes to control job processing, then you must create at least one TAC class in the KDCDEF generation. TAC classes can be created in two ways in the KDCDEF generation:
You generate a transaction code, and you specify a TAC class in the TACCLASS operand (TAC statement) that is then implicitly created by KDCDEF.
If you run the application without priority control (the application does not contain any TAC-PRIORITIES statements), then you can create the TAC classes by writing a TACCLASS statement.
If you created a TAC class in the KDCDEF generation, then the transaction codes you enter dynamically can be assigned to any TAC class between 1 and 16. The TAC classes are then created implicitly by openUTM. These TAC classes can be administered.
If the application is generated without TAC-PRIORITIES, then openUTM assigns the process numbers (TASKS) for implicitly created TAC classes as follows: 1 for dialog TAC classes (classes 1 through 8)
and 0 for asynchronous TAC classes (classes 9 through 16).Asynchronous TAC classes (9 through 16) are only created by openUTM, however, if you have set ASYNTASKS > 0 in the MAX statement in the generation.
In applications with TAC classes without priority control, you can only dynamically create transaction codes that start the program unit runs with blocking calls when TAC classes have been statically generated with PGWT=YES (dialog and/or asynchronous TAC classes).
Dialog and asynchronous TAC classes with PGWT=YES must therefore be generated explicitly in the KDCDEF generation with TACCLASS statements.
You must also set MAX TASKS-IN-PGWT > 0.In applications with priority control (with TAC-PRIORITIES statements) , you can only dynamically create transaction codes that start the program unit runs with blocking calls (TAC ...,PGWT=YES) when MAX TASKS-IN-PGWT>0 was set in the KDCDEF generation.
Prerequisites for user IDs
User IDs can only be entered dynamically if your application is generated with user IDs. In this case, your KDCDEF generation must contain at least one USER statement. At least one user ID must be configured with administration authorization, so that the calls for dynamic administration can be executed under this user ID.
If user IDs with ID cards are also to be configurable, the percentage of table locations that can be occupied by user IDs with ID card must be explicitly specified when reserving the table locations with the RESERVE statement.
You must generate the length of the ID card information statically in the KDCDEF generation using the MAX statement for user IDs with ID cards:
MAX...,CARDLTH=length