Your Browser is not longer supported

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

{{viewport.spaceProperty.prod}}

Vorgehensweise bei der Generierung von LU6.1-Verbindungen

Bei der Generierung von zwei Anwendungen, die über das LU6.1-Protokoll miteinander kommunizieren möchten, sollte wie folgt vorgegangen werden.

  1. LPAP- und SESCHA-Anweisungen

    Als erstes muss entschieden werden, ob jede der beiden Anwendungen in etwa gleich oft Aufträge an die andere Anwendung schickt, oder ob Aufträge überwiegend von einer der beiden Anwendungen gesendet werden.

    Im ersten Fall sollten in jeder der beiden Anwendungen jeweils zwei LPAP-Anweisungen generiert werden; im zweiten Fall wird in jeder der beiden Anwendungen nur jeweils eine LPAP-Anweisung benötigt.

    Dabei wird das LPAP, über das mehr Aufträge gesendet als empfangen werden, mit SESCHA ...,CONTWIN=NO generiert; das entsprechende LPAP in der Partner-Anwendung wird mit SESCHA ...,CONTWIN=YES generiert.

    Bei zwei LPAPs in einer Anwendung sollte ein LPAP mit
    SESCHA ... ,CONTWIN=NO und das andere mit
    SESCHA ...,CONTWIN=YES generiert werden.

    LPAP-Anweisung im Abschnitt "LPAP - LPAP-Partner für die verteilte Verarbeitung über LU6.1 definieren"
    Mit den folgenden Operanden können Sie einen LPAP-Partner als logischen Anschlusspunkt für die Partner-Anwendung definieren.

    • lpapname

      LPAP-Partnername, d.h. logischer Name der Partner-Anwendung, über den die Teilprogramme der lokalen Anwendung die Partner-Anwendung ansprechen. lpapname hat nur in der lokalen Anwendung eine Bedeutung.

    • SESCHA=

      Die unter sescha_name in der SESCHA-Anweisung definierten Session-Eigenschaften für die Kommunikation zwischen der lokalen Anwendung und der Partner-Anwendung werden dem LPAP-Partner zugewiesen.

    • PERMIT=

      legt die Berechtigungsstufe (Rechte zur Ausführung von Administrations- und Preselection-Funktionen) der Partner-Anwendung fest.

    • QLEV=

      gibt die maximale Anzahl der Asynchron-Nachrichten an, die in der Message Queue des LPAP-Partners stehen dürfen.

    • DEAD-LETTER-Q=

      gibt an, ob Asynchron-Nachrichten an den LPAP-Partner, die gelöscht werden, weil sie wegen eines permanenten Fehlers nicht gesendet werden konnten, in der Dead Letter Queue gesichert werden.

    • STATUS=

      definiert, ob mit der Partner-Anwendung sofort nach dem Start der lokalen Anwendung oder erst, nachdem der Status vom Administrator auf ON gesetzt wurde, zusammengearbeitet werden kann.

    • BUNDLE=

      macht das LPAP zum Slave-LPAP eines LU6.1-LPAP-Bündels und gibt das zugehörige Master-LPAP an.

    SESCHA-Anweisung im Abschnitt "SESCHA - Session-Eigenschaften für verteilte Verarbeitung über LU6.1 festlegen"
    Mit den folgenden Operanden können Sie Sessioneigenschaften definieren, die einem LPAP-Partner zugeordnet werden und damit der Partner-Anwendung, die sich über diesen LPAP-Partner anschließt.

    • sescha_name

      definiert den Namen, unter dem die Sessioneigenschaften zusammengefasst werden. Dieser Name wird in der LPAP-Anweisung beim Operanden SESCHA= angegeben, um die Session Charakteristika einem LPAP-Partner zuzuordnen.

    • CONTWIN=

      legt fest, ob die lokale Anwendung Contention Winner (NO) oder Contention Loser (YES) ist. Die Contention-Winner-Anwendung verwaltet die Session und regelt die Belegung der Session durch Aufträge.

      Standard: Bei PLU=N wird die lokale Anwendung Contention Loser, sonst Contention Winner.

    • PLU=

      legt fest, welche Anwendung den Aufbau der Session initiiert, d.h. ob die Partner-Anwendung die primary logical unit (PLU) ist (YES) oder die lokale Anwendung (NO).
      Für eine der beteiligten Anwendungen muss PLU=Y angegeben werden und für die andere Anwendung PLU=N.

    • CONNECT=

      legt fest, ob die lokale Anwendung beim Anwendungsstart die Verbindung zur Partner-Anwendung automatisch aufbauen soll (YES) oder ob die Verbindung zur Partner-Anwendung per Administrationskommando aufgebaut werden muss (NO).

    Beispiel

    Die Anwendung A sendet Aufträge an Anwendung B über das LPAP B1 und Anwendung B sendet Aufträge an Anwendung A über LPAP A2.

    Anwendung A:

    Anwendung B:

    LPAP B1, SESCHA=B1
    SESCHA B1, CONTWIN=NO, PLU=YES

    LPAP B2, SESCHA=B2
    SESCHA B2, CONTWIN=YES, PLU=NO

    LPAP A1, SESCHA=A1
    SESCHA A1, CONTWIN=YES, PLU=NO

    LPAP A2, SESCHA=A2
    SESCHA A2, CONTWIN=NO, PLU=YES



  2. BCAMAPPL-Anweisungen

    Als nächstes wird festgelegt, wieviele parallele Verbindungen zwischen zwei LPAPs generiert werden sollen. Entsprechend dieser Anzahl werden in beiden Anwendungen mittels der BCAMAPPL-Anweisung zusätzliche Transportsystem-Endpunkte generiert. Zwischen jedem Transportsystem-Endpunkt der einen Anwendung und jedem Transportsystem-Endpunkt der anderen Anwendung kann genau eine Verbindung aufgebaut werden. Sollen z.B. neun parallele Verbindungen zwischen zwei LPAPs generiert werden, dann werden also auf jeder Seite mindestens jeweils drei BCAMAPPL-Anweisungen benötigt.

    Werden in einer Anwendung zwei LPAPs zu einer Partner-Anwendung generiert, dann sollten die BCAMAPPLs dieser Anwendung in zwei disjunkte Gruppen aufgeteilt werden, wobei das eine LPAP nur über BCAMAPPLs der einen Gruppe kommuniziert, während das zweite LPAP nur BCAMAPPLs der zweiten Gruppe verwendet.

    BCAMAPPL-Anweisung im Abschnitt "BCAMAPPL - Weitere Anwendungsnamen definieren"
    Mit dem folgenden Operanden können Sie jeweils einen weiteren Anwendungsnamen für parallele Verbindungen zum Kommunikationspartner definieren.

    • appliname

      Zusätzlicher (BCAM-)Name der UTM-Anwendung.

    • T-PROT

      Gibt das Transportprotokoll an.
      Für BS2000 ist der Standard NEA, für Unix-, Linux- und Windows-Systeme ist der Standard RFC1006.

    Kommuniziert eine Anwendung mit mehreren Partner-Anwendungen, dann können die BCAMAPPLs, die für die Kommunikation mit einer Anwendung verwendet werden, auch für die Kommunikation zu den anderen Anwendungen eingesetzt werden.


  3. CON- und LSES-Anweisungen

    Als nächstes werden jeder LPAP-Anweisung für jede parallele Verbindung über dieses LPAP jeweils eine CON- und eine LSES-Anweisung zugeordnet. Jede CON- und jede LSES-Anweisung muss dabei in jeder der beteiligten Anwendungen generiert werden und beide Generierungen müssen zueinander korrespondieren.

    Es gilt:

    • Jeder CON-Name in der einen Anwendung entspricht einem BCAMAPPL-Namen in der anderen Anwendung und umgekehrt.

    • Jeder LSES-Name der einen Anwendung entspricht einem RSES-Namen in der anderen Anwendung und umgekehrt.

    CON-Anweisung im Abschnitt "CON - Verbindung für die verteilte Verarbeitung über LU6.1 definieren"
    Mit den folgenden Operanden können Sie dem LPAP-Partner in der lokalen Anwendung die reale Partner-Anwendung zuordnen.

    • remote_appliname

      Name der Partner-Anwendung, mit der über die logische Verbindung kommuniziert werden soll.

    • BCAMAPPL=

      bezeichnet einen Namen der lokalen Anwendung, wie er in der Steueranweisung MAX oder BCAMAPPL festgelegt wurde. Es darf kein BCAMAPPL-Name angegeben werden, für den T-PROT=SOCKET generiert ist.

    • LPAP=

      Name des LPAP-Partners der Partner-Anwendung, zu der die Verbindung aufgebaut werden soll. Der Name des LPAP-Partners, über den sich die Partner-Anwendung anschließt, muss mit der Anweisung LPAP lpapname definiert werden.
      Durch Angabe mehrerer CON-Anweisungen mit gleichem lpapname werden parallele Verbindungen zur Partner-Anwendung generiert.

    • PRONAM=

      Name des Partner-Rechners.

    Die CON-Anweisungen, mit denen in der lokalen Anwendung die Verbindung zur Partner-Anwendung und umgekehrt in der Partner-Anwendung die Verbindung zur lokalen Anwendung beschrieben werden, bezeichnen eine Verbindung. CON-Anweisungen müssen also immer paarweise auftreten. Bei parallelen Sessions werden für einen LPAP-Partner mehrere CON-Anweisungen generiert.

    Im Beispiel wird eine Zuordnung zwischen dem LPAP-Partner B1 (generiert in Anwendung A) und dem LPAP-Partner A1 (generiert in Anwendung B) geschaffen:

    LSES-Anweisung im Abschnitt "LSES - Sessionnamen für die verteilte Verarbeitung über LU6.1 definieren"
    Mit den folgenden Operanden können Sie gemeinsame Sessionnamen für die Verbindung vereinbaren und dem LPAP-Partner zuordnen.

    • local_sessionname

      Name der Session in der lokalen Anwendung.

    • RSES=

      Name der Session in der Partner-Anwendung.

    • LPAP=

      Name des LPAP-Partners, der der Partner-Anwendung zugeordnet wird. local_sessionname wird für die Kommunikation mit der Partner-Anwendung benutzt, die in der lokalen Anwendung dem LPAP-Partner lpapname zugeordnet ist.

    Sessionnamen werden in der lokalen und der Partner-Anwendung vereinbart. LSES-Anweisungen müssen daher ebenfalls immer paarweise auftreten. Da der Sessionname den LPAP-Partnern zugeordnet ist, muss die Zuordnung der LPAP-Partner durch die LSES-Anweisung mit der Zuordnung der LPAP-Partner durch die CON-Anweisungen identisch sein.

    Bei zwei einander zugeordneten LPAP-Partnern müssen die LSES- und RSES-Namen, die in den LSES-Anweisungen vereinbart wurden, zueinander passen (siehe folgendes Beispiel). Bei parallelen Sessions werden für einen LPAP-Partner lpapname mehrere LSES-Anweisungen mit unterschiedlichen Sessionnamen geschrieben.

    Das vorige Beispiel wird nun wie folgt ergänzt.


    Beispiel


    Anwendung A:

    Anwendung B:

    BCAMAPPL A11
    BCAMAPPL A12
    LPAP B1, SESCHA=B1 
    SESCHA B1, CONTWIN=NO, PLU=YES

    BCAMAPPL B11
    BCAMAPPL B12
    LPAP A1, SESCHA=A1 
    SESCHA A1, CONTWIN=YES, PLU=NO

    CON B11, BCAMAPPL=A11, LPAP=B1
    CON B12, BCAMAPPL=A11, LPAP=B1 
    CON B11, BCAMAPPL=A12, LPAP=B1
    CON B12, BCAMAPPL=A12, LPAP=B1
    LSES SESA11, RSES=SESB11, LPAP=B1 
    LSES SESA12, RSES=SESB12, LPAP=B1
    LSES SESA13, RSES=SESB13, LPAP=B1
    LSES SESA14, RSES=SESB14, LPAP=B1

    CON A11, BCAMAPPL=B11, LPAP=A1
    CON A11, BCAMAPPL=B12, LPAP=A1 
    CON A12, BCAMAPPL=B11, LPAP=A1
    CON A12, BCAMAPPL=B12, LPAP=A1
    LSES SESB11, RSES=SESA11, LPAP=A1 
    LSES SESB12, RSES=SESA12, LPAP=A1
    LSES SESB13, RSES=SESA13, LPAP=A1
    LSES SESB14, RSES=SESA14, LPAP=A1

    BCAMAPPL A21
    BCAMAPPL A22
    LPAP B2, SESCHA=B2 
    SESCHA B2, CONTWIN=YES, PLU=NO

    BCAMAPPL B21
    BCAMAPPL B22
    LPAP A2, SESCHA=A2 
    SESCHA A2, CONTWIN=NO, PLU=YES

    CON B21, BCAMAPPL=A21, LPAP=B2
    CON B22, BCAMAPPL=A21, LPAP=B2 
    CON B21, BCAMAPPL=A22, LPAP=B2
    CON B22, BCAMAPPL=A22, LPAP=B2
    LSES SESA21, RSES=SESB21, LPAP=B2 
    LSES SESA22, RSES=SESB22, LPAP=B2
    LSES SESA23, RSES=SESB23, LPAP=B2
    LSES SESA24, RSES=SESB24, LPAP=B2

    CON A21, BCAMAPPL=B21, LPAP=A2
    CON A21, BCAMAPPL=B22, LPAP=A2 
    CON A22, BCAMAPPL=B21, LPAP=A2
    CON A22, BCAMAPPL=B22, LPAP=A2
    LSES SESB21, RSES=SESA21, LPAP=A2 
    LSES SESB22, RSES=SESA22, LPAP=A2
    LSES SESB23, RSES=SESA23, LPAP=A2
    LSES SESB24, RSES=SESA24, LPAP=A2


    Hinweise

    • Bei Anwendungen mit verteilter Verarbeitung muss evtl. der Wert length der Anweisung MAX...,RECBUF=(number,length),... vergrößert werden. Hinweise, wie groß dieser Wert zu wählen ist, finden Sie im Abschnitt "Wiederanlaufbereich".

    • Das Verhalten einer Anwendung kann durch die Wahl der Timer (IDLETIME= in der SESCHA-Anweisung, CONCTIME und PTCTIME in der UTMD-Anweisung) beeinflusst werden.