Your Browser is not longer supported

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

{{viewport.spaceProperty.prod}}

OSI-LPAP - OSI-LPAP-Partner für verteilte Verarbeitung über OSI TP definieren

Mit der Steueranweisung OSI-LPAP definieren Sie in der lokalen Anwendung einen logischen Anschlusspunkt für eine Partner-Anwendung, mit der Sie über das OSI TP-Protokoll kommunizieren wollen. Der logische Anschlusspunkt für Partner-Anwendungen heißt OSI-LPAP-Partner. Für ihn legen Sie einen logischen Partnernamen und die folgenden logischen Verbindungseigenschaften fest:

  • Sie geben den Application Entity Title (AET) der Partner-Anwendung an. Der AET wird dann benötigt, wenn mit Transaktionssicherung (Commit Functional Unit) gearbeitet wird, oder aber ein heterogener Partner einen AET für den Verbindungsaufbau erwartet. Der AET setzt sich aus den folgenden Komponenten zusammen, die für die Partner-Anwendung definiert und hier angegeben werden:

  • Sie müssen den Application Context angeben, der bei der Kommunikation über das OSI TP-Protokoll mit der Partner-Anwendung verwendet wird. Wenn Sie keinen Standard-Application Context verwenden, definieren Sie Ihren Application Context mit der APPLICATION-CONTEXT-Anweisung, siehe Abschnitt "APPLICATION-CONTEXT - Application Context definieren". Wenn der Application Context des OSI-LPAP-Partners die CCR-Syntax enthält, müssen für die Partner-Anwendung ein AEQ und ein APT definiert werden.

  • Anzahl und Eigenschaften der Verbindungen zur Partner-Anwendung.

  • Zugriffsrechte der Partner-Anwendung in der lokalen Anwendung.
    Zur Definition der Zugriffsrechte stehen die Operanden KSET und ASS-KSET zur Verfügung. In KSET legen Sie die maximalen Zugriffsrechte des OSI TP-Partners fest, die der OSI TP-Partner hat, wenn er sich mit einer Benutzerkennung bei der lokalen Anwendung anmeldet. Mit dem Operanden ASS-KSET können Sie diese Zugriffsrechte einschränken. Die eingeschränkten Zugriffsrechte werden wirksam, wenn der OSI TP-Partner bei der Anmeldung keine Benutzerkennung übergibt, d.h. der „Association-User“ aktiv ist.

  • Administrationsberechtigung der Partner-Anwendung in der lokalen Anwendung.

  • Maximalwerte für die Message Queue des OSI-LPAP-Partners.

Ist ein Kommunikationspartner zu verschiedenen Zeiten in verschiedenen fernen
Systemen erreichbar, so können Sie diesem Partner mehrere Adressen zuordnen. Dazu weisen Sie einer OSI-LPAP-Anweisung mehrere OSI-CON-Anweisungen zu (OSI-CON-Anweisungen mit demselben osi_lpap_name, siehe Abschnitt "OSI-CON - Logische Verbindungen zum OSI TP-Partner definieren"). Es darf jedoch nur eine OSI-CON-Anweisung aktiv gesetzt werden. Umschalten auf eine Ersatzverbindung können Sie dann per Administration. Alle zu einem OSI-LPAP-Partner gehörenden OSI-CON-Verbindungen müssen denselben LOCAL-ACCESS-POINT haben. 

OSI-LPAP

 osi_lpap_name 
   ,APPLICATION-CONTEXT=application_context_name
 [ ,APPLICATION-ENTITY-QUALIFIER=application_entity_qualifier 
   ,APPLICATION-PROCESS-TITLE=object_identifier ]
 [ ,ASS-KSET=keysetname2 ]
   ,ASSOCIATION-NAMES=association_name
 [ ,ASSOCIATIONS=number ]
 [ ,BUNDLE=master-lpap-name]
 [ ,CONNECT=number ]
   ,CONTWIN=number
 [, DEAD-LETTER-Q={ NO | YES } ]
 [ ,IDLETIME=time ]
 [ ,KSET=keysetname1 ]
 [ ,PERMIT={ ADMIN | SATADM1 | ( ADMIN,SATADM )1 } ]
 [ ,QLEV=number ]
 [ ,STATUS={ ON | OFF } ]
 [ ,TERMN=termn_id ]

1 Nur auf BS2000-Systemen erlaubt

osi_lpap_name 

Name des OSI-LPAP-Partners der Partner-Anwendung, über den die Teilprogramme der lokalen UTM-Anwendung die Partner-Anwendung ansprechen.

osi_lpap_name kann max. 8 Zeichen lang sein.osi_lpap_name muss eindeutig sein und darf keinem weiteren Objekt der Namensklasse 1 zugeordnet sein. Siehe dazu auch Abschnitt "Eindeutigkeit der Namen und Adressen".

 APPLICATION-CONTEXT=application_context_name


Name des Application Context, der von der Partner-Anwendung verwendet werden soll.

Pflichtoperandopen

UTM unterstützt standardmäßig die folgenden Application Contexts:

  • UDTAC

  • UDTDISAC

  • XATMIAC

  • UDTCCR

  • UDTSEC

  • XATMICCR

Siehe dazu auch die APPLICATION-CONTEXT-Anweisung im Abschnitt "APPLICATION-CONTEXT - Application Context definieren". Wenn der generierte Application Context nicht mit dem von der Partner- Anwendung verwendeten übereinstimmt, lehnt openUTM den Verbindungsaufbau ab mit folgenden UTM-Meldungen:

P001 APPLICATION CONTEXT NOT SUPPORTED        oder
P011 Abstract Syntax nicht erlaubt

APPLICATION-ENTITY-QUALIFIER=application_entitiy_qualifier


Application-Entity-Qualifier der Partner-Anwendung. Der Application- Entity-Qualifier wird zusammen mit dem Application-Process-Title zur Adressierung einer Partner-Anwendung bei heterogener Kopplung verwendet bzw. wenn mit Transaktionssicherung (Commit Functional Unit) gearbeitet wird. application_entitiy_qualifier ist eine positive ganze Zahl, über die die Partner-Anwendung im fernen System gerufen wird.

Enthält der Application Context die CCR-Syntax, dann ist dieser Parameter Pflicht. Das Namenspaar application_entitiy_qualifier und object_identifier muss innerhalb der UTM-Anwendung eindeutig sein.

Der application_entitiy_qualifier, den Sie hier angeben, muss in der Partner-Anwendung einem Zugriffspunkt zugeordnet sein.

Minimalwert: 1
Maximalwert: 67108 863 (226-1)

APPLICATION-PROCESS-TITLE=object_identifier


Für object_identifier ist der Application Process Title der Partner- Anwendung anzugeben. Der Application Process Title wird zusammen mit dem Application Entity Qualifier zur Adressierung einer Partner- Anwendung bei heterogener Kopplung verwendet bzw. wenn mit Transaktionssicherung (Commit Functional Unit) gearbeitet wird.

Handelt es sich bei der Partner-Anwendung um eine UTM-Cluster-Anwendung, dann muss hier der Application Process Title (APT) einer Knoten-Anwendung angegeben werden. Dabei ist zu berücksichtigen, dass openUTM beim Start einer Knoten-Anwendung den für diese Anwendung generierten APT ggfs. um den Knoten-Index dieser Anwendung erweitert. Siehe hierzu auch Beschreibung des Operanden APPLICATION- PROCESS-TITLE bei der UTMD-Anweisung im Abschnitt "UTMD - Anwendungsparameter für verteilte Verarbeitung festlegen".

Enthält der Application Context die CCR-Syntax, dann ist dieser Parameter Pflicht. Das Namenspaar application_entitiy_qualifier (der OSI-LPAP- Anweisung ) und object_identifier muss innerhalb der UTM-Anwendung eindeutig sein.

Zur Definition des APT siehe die UTMD-Anweisung im Abschnitt "UTMD - Anwendungsparameter für verteilte Verarbeitung festlegen".

ASS-KSET= 

keysetname2

ist nur erlaubt, wenn die lokale Anwendung mit Benutzerkennungen generiert wird. ASS-KSET dürfen Sie nur zusammen mit KSET setzen.

Für keysetname2 ist der Name eines Keyset anzugeben. Das Keyset muss mit einer KSET-Anweisung definiert werden.

Mit ASS-KSET= legen Sie die minimalen Zugriffsrechte fest, die die Partner-Anwendung in der lokalen Anwendung ausüben kann.

Das in keysetname2 angegebene Keyset wird dann wirksam, wenn die Partner-Anwendung beim Aufbau der Association keine Benutzerkennung an openUTM übergibt.
Die Zugriffsrechte ergeben sich dann aus der Menge der Keycodes, die sowohl in dem mit KSET= als auch in dem mit ASS-KSET= generierten Keyset enthalten sind (Schnittmenge). Aus diesem Grund sollten alle Keycodes, die ASS-KSET=keysetname2 enthalten, auch in KSET=keyset- name1 enthalten sein.

Standard: kein Keyset
Es gelten immer die in KSET festgelegten Zugriffsrechte

ASSOCIATION-NAMES=association_name





Name, der für die logischen Verbindungen zur Partner-Anwendung innerhalb der lokalen Anwendung vergeben wird.

Der Name der Verbindungen setzt sich zusammen aus dem Wert von association_name als Präfix und einer Laufnummer. Die Laufnummer liegt zwischen 1 und dem Wert des Operanden ASSOCIATIONS, d.h. der Anzahl der parallelen Verbindungen. Der gesamte Name für eine Verbindung darf max. 8 Zeichen lang sein. Die maximale Länge des für association_name angegebenen Wertes ist abhängig von dem bei ASSOCIATIONS angegebenen Wert. Für die Anzahl der Verbindungen gilt:

Anzahl der Dezimalstellen des Wertes von ASSOCIATIONS + Anzahl der Zeichen von association_name <= 8

Beispiel

Angegeben wird: ASSOCIATIONS=10,
ASSOCIATION-NAMES=ASSOC

Namen der Verbindungen: ASSOC01, ASSOC02, ..., ASSOC10

Diese Namen werden in der lokalen UTM-Anwendung als Associationnamen benutzt. Sie dürfen keine Benutzerkennung (USER) und keine Sessionnamen für verteilte Verarbeitung über LU6.1 (LSES) mit demselben Namen generieren.

 ASSOCIATIONS=

number

Maximale Anzahl der parallelen Verbindungen zur Partner-Anwendung. Die maximale Anzahl paralleler Verbindungen zu einer Partner-Anwendung ist abhängig von den Schichten 1 - 6 des OSI-Referenzmodells von ISO (insbesondere der Transportschicht, Schicht 4).

Die Anzahl der parallelen Verbindungen muss mit der Generierung der Partner-Anwendung abgestimmt werden.

Standard: 1
Minimalwert: 1
Maximalwert: 21000
Die maximale Anzahl der Associations aller OSI-LPAP-Anweisungen einer UTM-Anwendung wird durch die Größe des Namensraums der UTM- Anwendung begrenzt (siehe Abschnitt "Anzahl der Namen").

BUNDLE=

master-lpap-name 

Name eines Master-LPAP. Durch die Angabe von master-lpap-name wird dieser OSI-LPAP-Partner zu einem Slave-LPAP des zugehörigen Master-LPAP.

Das Master-LPAP, das hier angegeben wird, muss mit einer Anweisung MASTER-OSI-LPAP definiert werden.

CONNECT= 

number

Anzahl der Verbindungen, die beim Start der lokalen Anwendung zu dieser Partner-Anwendung automatisch aufgebaut werden sollen. Der Aufbau einer Verbindung beim Start der Anwendung kann sowohl in der lokalen Anwendung als auch bei der Partner-Anwendung angefordert werden. Dadurch erreicht man, dass die Verbindung automatisch aufgebaut wird, sobald beide Partner verfügbar sind.

Auf BS2000-Systemen gilt:
Läuft die Partner-Anwendung auf Unix-, Linux- oder Windows- Systemen, sollte ein Wert größer 0 nur generiert werden, wenn das BS2000-System so konfiguriert ist, dass Verbindungen zu diesem Partner aktiv aufgebaut werden können.
Siehe auch Abschnitt "UTM- und BCAM-Generierung abstimmen (BS2000-Systeme)".

Standard: 0
Maximalwert: Anzahl der parallelen Verbindungen, die beim Operanden ASSOCIATIONS= angegeben wurde.

CONTWIN= 

number

Anzahl der Verbindungen, für die die lokale Anwendung der Contention Winner sein soll. Für die restlichen Verbindungen (Angabe bei ASSOCIATIONS minus Angabe bei CONTWIN) ist die lokale Anwendung der Contention Loser.

Der Contention Winner einer Verbindung übernimmt die Verwaltung der Verbindung. Aufträge können aber sowohl vom Contention Winner als auch vom Contention Loser gestartet werden. Im Konfliktfall, wenn beide Kommunikationspartner gleichzeitig einen Auftrag starten wollen, wird die Verbindung vom Auftrag des Contention Winner belegt.

Pflichtoperand

Die Anzahl der Contention Winner und Contention Loser muss mit der Generierung der Partner-Anwendung abgestimmt werden.

Contention Winner sollte für die Anwendung generiert werden, die am häufigsten Aufträge startet. Kann diese Anwendung keine Verbindungen zur Partner-Anwendung aufbauen, z.B. weil die BCMAP-Einträge fehlen, so kann diese Anwendung trotzdem Contention Winner sein, sofern die Partner-Anwendung alle Verbindungen automatisch aufbaut.

Minimalwert: 0
Maximalwert: Anzahl der parallelen Verbindungen, die beim Operanden ASSOCIATIONS= angegeben wurde.

DEAD-LETTER-Q=

gibt an, ob Asynchron-Nachrichten an diesen OSI-LPAP-Partner, die wegen eines permanenten Fehlers nicht gesendet werden konnten, in der Dead Letter Queue gesichert werden sollen.

Die Überwachung der Anzahl Nachrichten in der Dead Letter Queue wird mit der Anweisung MAX ...,DEAD-LETTER-Q-ALARM ein- bzw. ausgeschaltet.

    YES

Asynchron-Nachrichten an diesen OSI-LPAP-Partner, die wegen eines permanenten Fehlers nicht gesendet werden konnten, werden in der Dead Letter Queue gesichert, sofern (bei Message-Komplexen) kein negativer Quittungsauftrag definiert wurde.

    NO

Asynchron-Nachrichten an diesen OSI-LPAP-Partner werden nicht in der Dead Letter Queue gespeichert.

Standard: NO

Hauptaufträge zu Message-Komplexen (MCOM) mit negativen Quittungsaufträgen werden nie in der Dead Letter Queue gesichert, da im Fehlerfall die negativen Quittungsaufträge aktiviert werden.

Wird die Anzahl der Nachrichten der Dead Letter Queue mit QLEV beschränkt, können im Fehlerfall Nachrichten verloren gehen. Wird auf die Beschränkung der Anzahl verzichtet, muss der Pagepool von openUTM ausreichend groß generiert werden. Droht ein Pagepool-Engpass, kann die Dead Letter Queue bei laufender Anwendung mit  STATUS=OFF gesperrt werden.

IDLETIME= 

time

Zeit in Sekunden zur Überwachung des Idle-Zustands einer Verbindung. Wird während der mit time festgelegten Zeit die Verbindung von keinem Auftrag belegt, baut openUTM die Verbindung ab.

IDLETIME=0 bewirkt, dass der Idle-Zustand nicht überwacht wird.

Standard: 0
Minimalwert: 60
Maximalwert: 32767

Geben Sie einen Wert an, der größer als 0 und kleiner als der Minimalwert ist, dann ersetzt KDCDEF den Wert durch den Minimalwert.

KSET=

keysetname1

legt die maximalen Zugriffrechte der Partner-Anwendung in der lokalen Anwendung fest. In keysetname1 ist der Name eines Keysets anzugeben. Das Keyset muss mit einer KSET-Anweisung definiert werden.

Übergibt der OSI TP-Partner für einen OSI TP-Dialog keine Benutzerkennung an die lokale Anwendung, dann ergeben sich seine Zugriffsrechte für diesen OSI TP-Dialog aus der Menge der Keycodes, die sowohl in dem mit KSET= als auch in dem mit ASS-KSET= generierten Keyset vorhanden sind (Schnittmenge).
Das Keyset keysetname1 sollte deshalb alle Keycodes enthalten, die auch in dem mit ASS-KSET= generierten Keyset enthalten sind.

Übergibt der OSI TP-Partner eine Benutzerkennung, dann ergeben sich die Zugriffsrechte für diesen OSI TP-Dialog aus der Menge der Keycodes, die sowohl in dem Keyset der Benutzerkennung als auch in dem mit KSET generierten Keyset des OSI-LPAP enthalten sind.

Standard: kein Keyset,
d.h. es dürfen nur Services gestartet bzw. in der lokalen Anwendung generierte, entfernte Services (LTAC) adressiert werden, die nicht mit Lockcodes gesichert sind.

PERMIT=

legt die Berechtigungsstufe der Partner-Anwendung fest.

    ADMIN

Die Partner-Anwendung darf Administrationsfunktionen in der lokalen Anwendung ausführen.

    SATADM

Dieser Operandenwert gilt nur für BS2000-Systeme.

Die Partner-Anwendung kann SAT-Preselection-Funktionen in der lokalen Anwendung ausführen. D.h. die Partner-Anwendung kann die SAT-Protokollierung bestimmter Ereignisse ein- bzw. ausschalten (UTM-SAT-Administrations-Berechtigung).

    (ADMIN,SATADM)


Diese Operandenwerte gelten nur für BS2000-Systeme.

Die Partner-Anwendung kann Administrations- und SAT-Preselection- Funktionen in der lokalen Anwendung ausführen.

Standard: Wenn der Operand nicht angegeben wird, kann die Partner- Anwendung keine Administrations- und SAT-Preselection-Funktionen in der lokalen Anwendung ausführen.

QLEV=

queue_level_number

gibt die maximale Anzahl der asynchronen Nachrichten an, die in der Message Queue des OSI-LPAP-Partners stehen dürfen. Wird der Schwellwert überschritten, so werden weitere APRO-AM-Aufrufe an diesen LPAP-Partner mit der Meldung 40Z abgewiesen.

Standard: 32767
Minimalwert: 0
Maximalwert: 32767 (d.h., keine Beschränkung der Queue-Länge)

STATUS=

legt fest, ob der OSI-LPAP-Partner gesperrt ist. Der Status kann im Betrieb mit dem Administrationskommando KDCLPAP geändert werden.

    ON

Der OSI-LPAP-Partner ist nicht gesperrt. Es können Verbindungen zwischen der Partner-Anwendung und der lokalen Anwendung aufgebaut werden bzw. es bestehen bereits Verbindungen.

Standard: ON

    OFF

Der OSI-LPAP-Partner ist gesperrt. Es können keine Verbindungen zwischen der Partner-Anwendung und der lokalen Anwendung aufgebaut werden.

TERMN= 

termn_id 

Max. 2 Zeichen langes Kennzeichen für die Art des Kommunikationspartners. termn_id wird nicht von openUTM abgefragt, sondern vom Benutzer zur Auswertung gesetzt, um beispielsweise Terminaltypen abzufragen oder zu gruppieren etc. termn_id wird im KB-Kopf der Vorgänge eingetragen, die von der Partner-Anwendung in der lokalen Anwendung gestartet wurden.

Standard: A6