Your Browser is not longer supported

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

{{viewport.spaceProperty.prod}}

Format and uniqueness of object names

You must assign a name or logical address (clients and printers) to every object which you create dynamically in the configuration using KC_CREATE_OBJECT. Using this name and its logical address, it must be possible to uniquely identify the object in its application. Note the following rules when assigning names.

  • You cannot use any reserved names. (--> Reserved names)

  • The name of an object must be unique in the class of name belonging to the object name. (--> Unique names and addresses)

  • The names must not exceed the specified maximum length and can only contain certain characters (format). (--> Format of the names)

The names of objects tagged for deleting at a later point in time with KC_DELETE_OBJECT may not be used for objects in the same class of name. The names of user IDs and the names of connections for distributed processing by means of LU6.1 that are deleted immediately can be reassigned again immediately.

Reserved names

Names of transaction codes starting with KDC are reserved for transaction codes in the event services and the administration commands. Names starting with KDC must not therefore be used for other objects.

In UTM applications on BS2000 systems, program unit names must not begin with a prefix that is used for compiler runtime modules (e.g. IT, IC).

In UTM applications on Unix, Linux or Windows systems, names of objects must also not start with KC, x, ITS or mF. External names (e.g. program unit names) should not begin with ‘f_', ‘n_', ‘t_', ‘a_', ‘o_', ‘p_' or ‘s_'. ‘t_' is reserved for PCMX. ‘a_', ‘o_', ‘p_' and ‘s_' are reserved for OSS.

Any names reserved on a specific platform should not be used on any of the other platforms, in order to render the applications portable.

Unique names and addresses

The names and addresses of objects in a UTM application are summarized in name classes. Within each name class, the object names must be uniquely identified. They cannot be assigned to several objects. There are three classes of name:


The following objects belong to the 1st class of names:

  • LTERM partners (object type KC_LTERM);
    the LTERM partners of the LTERM pools also belong to this class.

  • Transaction codes and TAC queues (object type KC_TAC).

  • LPAP and OSI-LPAP partners for the server-server communication (object type KC_LPAP and KC_OSI_LPAP).


The following objects belong to the 2nd class of names:

  • User IDs, including the associated queues (object type KC_USER)

  • Sessions for distributed processing using LU6.1 (object type KC_LSES)

  • Connections and associations for distributed processing using OSI TP (object type KC_OSI_ASSOCIATION)


The following objects belong to the 3rd class of names:

  • Clients and printers (object type KC_PTERM).
    In this context, clients are: terminals, UPIC clients, TS applications (DCAM, CMX applications and UTM applications) which do not use LU6.1 and OSI TP protocols for communication.

  • Name of the partner application for distributed processing using protocol LU6.1 (object type KC_CON).

  • Name of the partner application in the case of distributed processing using the OSI TP protocol.
    Even if it is not possible to generate OSI-CONs dynamically, the names already generated for OSI-CONs are already allocated to this name class and cannot be used for other objects of this name class.

  • Multiplex connections (object type KC_MUX, only on BS2000 systems).

The objects listed in the 3rd class of name are communication partners for the UTM application. They or the connections to them must be uniquely identifiable for openUTM. For this reason, every communication partner must be identified with a logical address. The logical address is a name triplet made up of the following components:

  1. Name of the communication partner (pt_name, co_name of the LU6.1 connection, mx_name). This is the symbolic name by which the communication partner is known to the transport system.

  2. Name of the computer on which the communication partner is located (pronam).

  3. Name of the local application via which the connection to the communication partner is established (bcamappl or ACCESS-POINT). Even if OSI TP connections cannot be generated dynamically, the names that have already been generated for ACCESS POINTS must be taken into account.

Each communication partner must have a different name triplet.

Format of the names

All names which you define must conform to the following conventions:

  • The names of LTERM partners, clients and printers (KC_PTERM), transaction codes, user IDs, LU6.1 connections and sessions as well as transaction codes for remote services must only be 1 to 8 characters in length.

  • The names of program units can be up to 32 characters in length if the application was generated using load modules/shared objects/DLLs.

  • Permissible characters for object names in a UTM application on BS2000 systems are:A,B,C,...,Z, 0,1,...,9, #, @, $. Any combination of these characters is permitted.

  • Permissible characters for object names in a UTM application on Unix, Linux systems and Windows systems are: A,B,C,...,Z, a, b, c,..., z, 0,1,...,9, #, @, $.