Generierung für die verteilte Verarbeitung über OSI TP

Für die Generierung der Kommunikationspartner und der Verbindungen zu diesen Partnern verfügen Sie über die folgenden KDCDEF-Anweisungen:

Anweisung	Funktion
ABSTRACT-SYNTAX	Abstrakte Syntax für die Benutzerdaten definieren: Vergabe eines eindeutigen Object Identifiers Transfersyntax für die Datenübertragung zuordnen
ACCESS-POINT	Adresse und Name des lokalen OSI TP-Zugriffspunktes definieren: Application-Entity-Qualifier (AEQ) der lokalen Anwendung definieren (Adresskomponente des Application Entity Title)
APPLICATION-CONTEXT	Anwendungskontext für die Kommunikation mit der Partner-Anwendung definieren: Abstrakte Syntax für die Benutzerdaten zuordnen Vergabe eines eindeutigen Object Identifiers
LTAC	Lokale TAC-Namen für Services in der Partner-Anwendung vergeben, über die die fernen Services in der lokalen Anwendung angesprochen werden
MASTER-OSI-LPAP	Name und Eigenschaften des Master-LPAP in einem OSI-LPAP-Bündel festlegen (siehe Abschnitt "OSI-LPAP-Bündel")
OSI-CON	Verbindungen zwischen der lokalen Anwendung und dem fernen Partner definieren und dem OSI-LPAP-Partner zuordnen: Lokalen OSI TP-Zugriffspunkt angeben Netzadresse der Partner-Anwendung angeben
OSI-LPAP	OSI-LPAP-Partner als logischen Anschlusspunkt für die Partner-Anwendung definieren: Application Entity Title, d.h. APT und AEQ der Partner-Anwendung angeben Application Context der Partner-Anwendung angeben Anzahl der (parallelen) Verbindungen zum Partner und Namen der Verbindungen festlegen Anzahl der Verbindungen, die beim Anwendungsstart automatisch aufgebaut werden Anzahl der Verbindungen, für die die lokale Anwendung Contention Winner sein soll Zugriffsrechte der Partner-Anwendung in der lokalen Anwendung Administrationsberechtigungsstufe der Partner-Anwendung Maximalwerte für Message Queue des OSI-LPAP-Partners festlegen Status des OSI-LPAP-Partners bei Verbindungsaufbau ggf. das OSI-LPAP zum Slave-LPAP eines OSI-LPAP-Bündels machen und das zugehörige Master-LPAP angeben ggf. angeben, ob Asynchron-Nachrichten an den OSI-LPAP-Partner, die gelöscht werden, weil sie wegen eines permanenten Fehlers nicht gesendet werden konnten, in der Dead Letter Queue gesichert werden.
TRANSFER-SYNTAX	Transfersyntax für die Datenübertragung definieren: Vergabe eines eindeutigen Object Identifiers
UTMD	Anwendungsglobale Werte und Adresse der lokalen UTM-Anwendung festlegen Application-Process-Title (APT) definieren (Adresskomponente des Application Entity Title) Maximale Wartezeit für Associationaufbau Wartezeit für Quittung bei Asynchron-Nachrichten
Auf Unix-, Linux- und Windows-Systemen stehen zusätzlich folgende Parameter zur Verfügung:
MAX XAPTPSHMKEY	Schlüssel für das XAPTP Shared Memory Segment definieren
MAX OSISHMKEY	Schlüssel für das Shared Memory Segment von OSS definieren
MAX OSI-SCRATCH-AREA	Arbeitsbereichgröße für die dynamische Ablage von Daten festlegen

Für die Kommunikation mit dem OSI TP-Protokoll müssen Sie:

• Application Entity Title (AET) generieren.
  Mit der Anweisung UTMD...,APPLICATION-PROCESS-TITLE= legen Sie den Application Process Title (APT) als Adresskomponente des AET für Ihre Anwendung fest. Ein ferner Partner, der AETs verlangt, muss diesen APT kennen, um eine Verbindung aufbauen zu können.

  Mit der Anweisung ACCESS-POINT...,APPLICATION-ENTITY-QUALIFIER= legen Sie den AEQ als Adresskomponente des AET für den Zugriffspunkt der lokalen Anwendung fest. Eine Partner-Anwendung muss den AEQ des Zugriffspunkts kennen, über den die Kommunikation mit der lokalen Anwendung erfolgen soll.

  Den AET ordnen Sie dem OSI-LPAP-Partner zu. In der Anweisung OSI-LPAP geben Sie mit den Operanden APPLICATION-PROCESS-TITLE= den APT und mit APPLICATION-ENTITY-QUALIFIER= den Application Entity Qualifier (AEQ) des Zugriffspunkts für die Partner-Anwendung an. Der AEQ muss in der fernen Partner-Anwendung für den Zugriffspunkt generiert worden sein.

  Unix-, Linux- und Windows-Systeme

  Für UTM-Cluster-Anwendungen gilt: Wenn Sie in der UTMD-Anweisung für die OSI-TP-Kopplung einen APT mit weniger als 10 Elementen angeben, dann ergänzt UTM den generierten APT für jede Knoten-Anwendung um einen Index (1, 2, ...). Damit wird die Eindeutigkeit des AET gewährleistet. Daher wird empfohlen, in UTM-Cluster-Anwendungen maximal 9 Elemente zu generieren.

• Application Context für den Datenaustausch mit der Partner-Anwendung definieren.

  Den Application Context, der bei der Kommunikation mit der Partner-Anwendung verwendet werden soll, generieren Sie mit der Anweisung APPLICATION-CONTEXT, falls Sie nicht mit einem der UTM-Standard-Application Contexts im Abschnitt "OSI-Begriffe" arbeiten. Sie ordnen dabei dem Application Context definierte Abstrakte Syntaxen und einen eindeutigen Object Identifier zu.

  Die Abstrakte Syntax für die Übertragung der Benutzerdaten wird mit der Anweisung ABSTRACT-SYNTAX definiert, dabei wird ihr ein eindeutiger Object Identifier zugewiesen.

  Die Transfersyntax, die festlegt, wie die Benutzerdaten für die Datenübertragung encodiert bzw. decodiert werden, definieren Sie mit der Anweisung ABSTRACT-SYNTAX. Identifiziert wird die Transfersyntax durch einen eindeutigen Object Identifier.

• Zugriffspunkt auf die Dienste von OSI TP für Ihre UTM-Anwendung definieren, damit Ihre Anwendung bei der Kommunikation über OSI TP adressierbar ist.

  Mit der Anweisung ACCESS-POINT wird die Adresse des Zugriffspunktes innerhalb des lokalen Systems angegeben. Mit ACCESS-POINT wird dem Zugriffspunkt auch ein symbolischer Name zugeordnet, über den der Zugriffspunkt in der lokalen UTM-Anwendung angesprochen werden kann.

  Die in ACCESS-POINT festgelegte Adresse muss innerhalb der UTM-Anwendung und innerhalb des lokalen Systems (auf BS2000-Systemen) pro Host eindeutig sein. Sie ist deshalb mit dem Netzverwalter bzw. Systemverwalter Ihres Systems abzusprechen.

  Eine Partner-Anwendung, die mit der lokalen Anwendung über das OSI TP-Protokoll kommunizieren will, identifiziert die lokale UTM-Anwendung über die Adresse des Zugriffspunktes und die Netzadresse Ihres Systems. Die Netzadresse des Zugriffspunktes muss bei der Generierung der fernen Partner-Anwendungen angegeben werden. 

  Unix-, Linux- und Windows-Systeme

  Bitte beachten Sie die maximale Anzahl von Verbindungen, die über einen Zugriffspunkt zu einer Zeit aufgebaut werden können. Details siehe ACCESS-POINT-Anweisung im Abschnitt "ACCESS-POINT- OSI TP-Zugriffspunkt einrichten".

• Logischen Anschlusspunkt (OSI-LPAP-Partner) für die Partner-Anwendung und die Verbindungen zwischen der lokalen Anwendung und ihr beschreiben.

  Die Beschreibung erfolgt über eine OSI-LPAP- und eine OSI-CON-Anweisung. Pro Partner-Anwendung muss eine OSI-LPAP-Anweisung generiert werden. Die Verbindungen zwischen der UTM-Anwendung und dem Kommunikationspartner werden in der OSI-CON-Anweisung definiert. Die Definition erfolgt über die beiden Zugriffspunkte (in der lokalen und in der Partner-Anwendung), zwischen denen die Verbindungen aufgebaut werden sollen. Dazu geben Sie in der OSI-CON-Anweisung die Netzadresse des fernen Zugriffspunktes und den Namen des lokalen Zugriffspunktes (in ACCESS-POINT definiert) an. Die Anzahl und die Namen der parallelen Verbindungen (Associations) zu der Partner-Anwendung legen Sie mit der Anweisung OSI-LPAP fest. Die Adresse des fernen Zugriffspunktes muss mit der Adresse des in der Partner-Anwendung generierten Zugriffspunktes übereinstimmen.

  Sollen Verbindungen automatisch aufgebaut werden, sobald beide Kommunikationspartner verfügbar, also gestartet sind, so muss bei der Generierung beider Partner angegeben werden, dass die Verbindungen automatisch beim Start der Anwendung aufgebaut werden sollen. Bei openUTM generieren Sie dies mit der Anweisung OSI-LPAP...,CONNECT=. Der Partner, der zuletzt gestartet wird, baut dann die Verbindung auf. Mit OSI-LPAP...,CONTWIN= legen Sie auch fest, für wie viele Verbindungen zu dem Kommunikationspartner die lokale Anwendung Contention Winner sein soll.

• Den Services der Partner-Anwendungen lokal Transaktionscodes zuordnen, über die die fernen Services in der lokalen Anwendung angesprochen werden.

  Jeder dieser Transaktionscodes wird mit einer Steueranweisung LTAC definiert. Der Transaktionscode kann mit LTAC..., LPAP=osi-lpap-name der Partner-Anwendung eindeutig zugeordnet werden. Zusätzlich muss mit LTAC...,RTAC= der Transaktionscode des Teilprogramms in der Partner-Anwendung angegeben werden. Diesen Transaktionscode müssen Sie vom Betreiber der Partner-Anwendung erfragen. Falsche Angaben für Namen und Art des fernen TACs erkennt das Generierungstool KDCDEF nicht, da es keine Informationen über die Konfiguration der Partner-Anwendung hat. Ein Fehler tritt erst dann auf, wenn die lokale Anwendung diesen LTAC anfordert.

Zusätzlich können Sie für die Kommunikation über OSI TP:

• Globale Werte für alle Verbindungen der Anwendung zu Kommunikationspartnern festlegen.

  Mit der Anweisung UTMD können Sie Wartezeiten auf Quittungen vom Kommunikationspartner begrenzen und festlegen, wieviele Aufträge an Partner-Anwendungen insgesamt (über OSI TP und LU6.1) gleichzeitig in der lokalen Anwendung bearbeitet werden dürfen. Mit entsprechenden Grenzwerten können Sie vermeiden, dass Verbindungen blockiert, bzw. Verbindungen zu früh abgebrochen werden, und dass alle Tasks der Anwendung durch Aufträge ferner Anwendungen belegt sind. Die festgelegten Werte gelten auch für die Kommunikation über LU6.1.

• Ersatzverbindungen generieren

  Ersatzverbindungen generieren Sie, indem Sie eine Verbindung mit zwei OSI-CON-Anweisungen beschreiben. Ersatzverbindungen müssen Sie generieren, wenn Sie mit verschiedenen Partnern alternativ zusammenarbeiten möchten, ohne in den Teilprogrammen darauf Rücksicht nehmen zu müssen. Die beiden Partner können sich in unterschiedlichen Systemen befinden. Ersatzverbindungen generieren Sie, indem Sie einer OSI-LPAP-Anweisung zwei OSI-CON-Anweisungen mit unterschiedlichen Partneradressen (Adressen des fernen Zugriffspunktes) zuordnen. So ordnen Sie zwei verschiedenen Partnern den gleichen logischen Anschlusspunkt (LPAP-Partner) zu. Sie dürfen jedoch nicht beide Verbindungen zu den alternativen Partner-Anwendungen gleichzeitig aktiv setzen. Deshalb darf nur jeweils in einer OSI-CON-Anweisung ACTIVE=YES angegeben werden. Umschalten auf die Ersatzverbindung zur alternativen Partner-Anwendung können Sie mit dem Administrationskommando KDCLPAP.

• Zugriffsschutz für Services der Partner-Anwendung definieren

  Mit der Anweisung LTAC..., LOCK= oder LTAC..., ACCESS-LIST= können Sie einen Service der Partner-Anwendung mit einem Zugriffsschutz versehen. Es können lokal dann nur Teilprogramme diesen Service adressieren, die unter einer Benutzerkennung (KCBENID) und von einem Client (KCLOGTER) aus gestartet wurden, die die entsprechenden Zugriffsrechte haben.

• Zugriffsschutz für Services der lokalen Anwendung definieren

  Soll die Partner-Anwendung nur bestimmte Services der lokalen Anwendung aufrufen können, dann schützen Sie kritische Services in der Anweisung TAC mit einem Lockcode oder einer Access-Liste. Mit einer KSET-Anweisung können Sie ein Keyset definieren, das die Keycodes für Services enthält, die die Partner-Anwendung nutzen darf. Das Keyset ordnen Sie dem logischen Anschlusspunkt der Partner-Anwendung mit der Anweisung OSI-LPAP...,KSET= zu. Die Partner-Anwendung darf dann nur die TACs aufrufen, die entweder nicht gesichert sind oder zu denen die Partner-Anwendung die entsprechenden Zugriffsrechte besitzt.

• Administrationsberechtigung für TACs der Partner-Anwendung vergeben

  In der OSI-LPAP-Anweisung können Sie festlegen, ob der Partner in der lokalen Anwendung Administrationsberechtigung erhalten soll. Die Berechtigungsstufe wird mit OSI-LPAP...,PERMIT= festgelegt.

• UTM-SAT-Administrationsberechtigung für TACs der Partner-Anwendung vergeben (nur BS2000-Systeme)

  Mit OSI-LPAP...,PERMIT= können Sie auch festlegen, ob der Partner in der lokalen Anwendung UTM-SAT-Administrationsberechtigung erhalten soll.

Die unten stehende Grafik fasst zusammen, in welchen Punkten die Generierung der lokalen Anwendung und die Generierung der Partner-Anwendung aufeinander abgestimmt werden müssen. Es wird ein von openUTM generierter Standard-Application-Context verwendet, deshalb muss keine APPLICATION-CONTEXT-Anweisung geschrieben werden.

Weitere Informationen zur Generierung von Anwendungen mit verteilter Verarbeitung insbesondere über OSI TP können Sie der Beispielgenerierung „ComfoTRAVEL“ im Abschnitt "Beispielgenerierung ComfoTRAVEL" entnehmen.

Bild 8: Abstimmung bei der Generierung von OSI TP-Anwendungen