Format und Eindeutigkeit der Objektnamen

Jedem Objekt, das Sie mit KC_CREATE_OBJECT dynamisch in die Konfiguration eintragen, müssen Sie einen Namen bzw. eine logische Adresse (Clients und Druckern) zuordnen. Über seinen Namen bzw. seine logische Adresse muss das Objekt innerhalb der Anwendung eindeutig identifizierbar sein. Folgende Regeln sind bei der Namensvergabe zu beachten.

• Sie dürfen keinen reservierten Namen benutzen. (--> Reservierte Namen)

• Der Name eines Objektes muss innerhalb der Namensklasse eindeutig sein, zu der das Objekt gehört. (--> Eindeutigkeit der Namen und Adressen)

• Die Namen dürfen die vorgeschriebene Maximallänge nicht überschreiten und nur bestimmte Zeichen enthalten (Format). (--> Format der Namen)

Die Namen von Objekten, die zuvor mit KC_DELETE_OBJECT verzögert gelöscht (zum Löschen vorgemerkt) wurden, dürfen für Objekte derselben Namensklasse nicht verwendet werden. Namen von Benutzerkennungen und Namen von Verbindungen für die verteilte Verarbeitung über LU6.1, die sofort gelöscht wurden, können sofort wieder vergeben werden.

Reservierte Namen

Namen von Transaktionscodes, die mit KDC beginnen, sind für die Transaktionscodes der Event-Services und der Admininistrationskommandos reserviert. Namen die mit KDC beginnen, dürfen also für andere Objekte nicht verwendet werden:

In UTM-Anwendungen auf BS2000-Systemen sollten Teilprogrammnamen nicht mit einem Präfix beginnen, das für Compiler-Laufzeitmodule verwendet wird (z.B. IT, IC).

In UTM-Anwendungen auf Unix-, Linux- und Windows-Systemen sollten die Namen der Objekte nicht mit KC, x, ITS oder mF beginnen. Externe Namen (z.B. Teilprogrammnamen) sollten nicht mit 't_', 'a_', 'o_', 'p_' oder 's_' beginnen. 't_' ist für PCMX reserviert. 'a_', 'o_','p_' und 's_' sind für OSS reserviert.

Alle Namen, die auf einer bestimmten Plattformen reserviert sind, sollten auf den anderen Plattformen ebenfalls nicht verwendet werden, damit die Anwendung portierbar bleibt.

Eindeutigkeit der Namen und Adressen

Die Namen und Adressen der Objekte einer UTM-Anwendung sind in Namensklassen zusammengefasst. Innerhalb einer Namensklasse müssen die Objektnamen eindeutig sein, sie dürfen nicht mehreren Objekten zugeordnet sein. Es gibt drei Namensklassen:

Zur 1. Namensklasse gehören die Namen folgender Objekte:

• LTERM-Partner (Objekttyp KC_LTERM);
  dazu gehören auch die LTERM-Partner der LTERM-Pools.

• Transaktionscodes und TAC-Queues (Objekttyp KC_TAC).

• LPAP- bzw. OSI-LPAP-Partner für die Server-Server-Kommunikation (Objekttyp KC_LPAP und KC_OSI_LPAP).

Zur 2. Namensklasse gehören die Namen folgender Objekte:

• Benutzerkennungen einschließlich zugehöriger Queues (Objekttyp KC_USER)

• Sessions für die verteilte Verarbeitung über LU6.1 (Objekttyp KC_LSES)

• Verbindungen und Associations für die verteilte Verarbeitung über OSI TP (Objekttyp KC_OSI_ASSOCIATION)

Zur 3. Namensklasse gehören die Namen folgender Objekte:

• Clients und Drucker (Objekttyp KC_PTERM).
  Clients sind hierbei: Terminals, UPIC-Clients, TS-Anwendungen (DCAM-, CMX-Anwendungen und UTM-Anwendungen), die bei der Kommunikation das LU6.1- und das OSI TP-Protokoll nicht nutzen.

• Name der Partner-Anwendung bei der verteilten Verarbeitung über das Protokoll LU6.1 (Objekttyp KC_CON).

• Name der Partner-Anwendung bei der verteilten Verarbeitung über das Protokoll OSI TP.
  Auch wenn OSI-CONs nicht dynamisch erzeugt werden können, sind die bereits für OSI-CONs generierten Namen für diese Namensklasse vergeben und können nicht für andere Objekte dieser Namensklasse verwendet werden.

• Multiplexanschlüsse (Objekttyp KC_MUX, nur auf BS2000-Systemen).

Die in der 3. Namensklasse aufgeführten Objekte sind Kommunikationspartner der UTM-Anwendung. Sie bzw. die Verbindungen zu ihnen müssen für openUTM eindeutig identifizierbar sein. Deshalb wird jeder Kommunikationspartner über eine logische Adresse identifiziert. Die logische Adresse ist ein Namenstripel, das sich aus den folgenden Komponenten zusammensetzt:

1. Name des Kommunikationspartners (pt_name, co_name der LU6.1-Verbindung, mx_name). Das ist der symbolische Name, unter dem der Kommunikationspartner beim Transportsystem bekannt ist.

2. Name des Rechners, auf dem sich der Kommunikationspartner befindet (pronam).

3. Name der lokalen Anwendung, über den die Verbindung zum Kommunikationspartner aufgebaut wird (bcamappl oder ACCESS-POINT). Auch wenn OSI TP-Verbindungen nicht dynamisch erzeugt werden können, sind die bereits für ACESS-POINTs generierten Namen zu berücksichtigen.

Die Namenstripel der Kommunikationspartner müssen voneinander verschieden sein.

Format der Namen

Alle Namen, die Sie definieren, müssen folgenden Konventionen entsprechen:

• Die Namen von LTERM-Partnern, Clients und Druckern (KC_PTERM), Transaktionscodes, Benutzerkennungen, Keysets, LU6.1-Verbindungen und Sessions sowie Transaktionscodes für ferne Services dürfen 1 bis 8 Zeichen lang sein.

• Die Namen von Teilprogrammen dürfen, wenn die Anwendung mit Lademodulen/Shared Objects/DLLs generiert ist, bis zu 32 Zeichen lang sein.

• Erlaubte Zeichen für die Objektnamen in einer UTM-Anwendung auf BS2000-Systemen sind: A,B,C,...,Z, 0,1,...,9, #, @, $. Es sind beliebige Kombinationen dieser Zeichen erlaubt.

• Erlaubte Zeichen für die Objektnamen in einer UTM-Anwendung auf Unix-, Linux- oder Windows-Systemen sind: A,B,C,...,Z, a,b,c,...,z, 0,1,...,9, #, @, $.