BCAMAPPL - Weitere Anwendungsnamen definieren

Mit der BCAMAPPL-Anweisung können Sie der UTM-Anwendung weitere Anwendungsnamen für die Client/Server-Kommunikation und die verteilte Verarbeitung über LU6.1 zuordnen. Durch jeden Anwendungsnamen wird ein Transportsystem-Endpunkt definiert, über den Verbindungen zur UTM-Anwendung aufgebaut werden können.

Der primäre Anwendungsname der UTM-Anwendung wird in der MAX-Anweisung mit dem Operanden APPLINAME festgelegt. Für ihn ist Folgendes zu beachten:

• BS2000-Systeme:
  Sie dürfen BCAMAPPL-Anweisungen nur für weitere BCAM-Namen der Anwendung absetzen. Der primäre Anwendungsname darf nicht in einer BCAMAPPL-Anweisung angegeben werden.

• Unix-, Linux- und Windows-Systeme:
  Sie müssen eine BCAMAPPL-Anweisung für den primären Anwendungsnamen absetzen, wenn über ihn auch Verbindungen zu Partner-Anwendungen oder Clients aufgebaut werden sollen.

• Pro Anwendungsnamen können zu einer Zeit maximal 1000 Verbindungen aufgebaut werden können. Wenn Sie in Ihrer Anwendung mehr Verbindungen benötigen, dann müssen Sie mehrere Anwendungsnamen definieren.

Die Steueranweisung BCAMAPPL kann mehrfach angegeben werden. Sie sollten jedoch nur soviele BCAMAPPL-Anweisungen, d.h. zusätzliche Anwendungsnamen, wie nötig generieren, um keine unnötigen Ressourcen zu belegen.

Es ist nötig, weitere Anwendungsnamen für Ihre UTM-Anwendung zu generieren, wenn:

• über LU6.1 parallele Verbindungen zu anderen Anwendungen (verteilte Verarbeitung) definiert werden sollen; in diesem Fall sind zumindest in einer der beteiligten Anwendungen zusätzliche Anwendungsnamen zu generieren.

• mit einem Kommunikationspartner über die Socket-Schnittstelle (native TCP/IP) kommuniziert werden soll.
  Für die Kommunikation über die Socket-Schnittstelle benötigen Sie eigene BCAMAPPL-Namen (mit T-PROT=SOCKET). Diese können nicht für die Kommunikation über andere Transportprotokolle verwendet werden.

• BS2000-Systeme:

  • zu einem Partner einer UTM-Anwendung, der mit PTYPE=APPLI, PTYPE=UPIC-R oder als Partner einer LU6.1-Anwendung generiert ist, ein Transportprotokoll ungleich NEA verwendet werden soll,

  • zu einem Partner einer UTM-Anwendung Multiplexverbindungen aufgebaut werden sollen,

  • mit einer UTM-Anwendung auf Unix-, Linux- oder Windows-Systemen kommuniziert werden soll.

• Unix-, Linux- und Windows-Systeme:
  • Sie Verbindungen über das Protokoll RFC1006 Verbindungen aufbauen wollen. In diesem Fall müssen Sie für die Kommunikation über RFC1006 einen eigenen BCAMAPPL-Namen definieren.

In allen K-Meldungen, die den UTM-Anwendungsnamen enthalten, erscheint der mit der MAX-Anweisung und nicht der mit der BCAMAPPL-Anweisung festgelegte Name.

BCAMAPPL-Anweisung auf BS2000-Systemen

BCAMAPPL

appliname ,LISTENER-PORT=number nur bei T-PROT=SOCKET erlaubt und Pflicht   [ ,SIGNON-TAC={ *NONE | tacname } ]   [ ,T-PROT={ NEA | ISO | RFC1006 | SOCKET |               (SOCKET [,*ANY | *USP | *HTTP] [,SECURE])} ]   [ ,USER-AUTH = *NONE | *BASIC ]

appliname	Zusätzlicher BCAM-Name der UTM-Anwendung. appliname kann max. 8 Zeichen lang sein. appliname darf nicht mit den Anwendungsnamen identisch sein, die Sie in MAX...,APPLINAME= bzw. ACCESS-POINT...,TRANSPORT-SELECTOR= angeben. appliname muss im lokalen System pro Host eindeutig sein.
LISTENER-PORT=	nummer darf nur zusammen mit T-PROT=SOCKET angegeben werden. In diesem Fall ist LISTENER-PORT= Pflichtoperand. LISTENER-PORT= legt die Portnummer fest, an der openUTM auf Verbindungsaufbauwünsche von außen wartet. Ist LISTENER-PORT zusammen mit T-PROT=(SOCKET,..., SECURE) generiert, dann wird zusätzlich zu der mit number definierten Port-Nummer auch noch die Port-Nummer number+1 durch die UTM-Anwendung belegt. Die zweite Port-Nummer wird für die Kommunikation zwischen der UTM-Anwendung und dem Reverse Proxy benötigt. Es sind alle Portnummern zwischen 1 und 65535 erlaubt. Jede Portnummer kann im lokalen System nur einmal verwendet werden. Beim Starten von openUTM kann es sein, dass vom System oder anderen TCP/IP-Anwendungen bereits Portnummern reserviert sind oder dass privilegierte Portnummern nicht benutzt werden dürfen. In diesem Fall wird der Start der UTM-Anwendung abgebrochen.
SIGNON-TAC=	Gibt an, ob für Verbindungen, die über den Anwendungsnamen appliname (=Transportsystemzugangspunkt) aufgebaut werden, ein Anmelde-Vorgang gestartet werden soll oder nicht. Soll ein Anmelde-Vorgang gestartet werden, dann müssen Sie den Namen des Transaktionscodes angeben, über den der Anmelde-Vorgang gestartet wird.
*NONE	Für Verbindungen, die über den Anwendungsnamen appliname zu der UTM-Anwendung aufgebaut werden, soll kein Anmelde-Vorgang gestartet werden, unabhängig davon, ob der TAC KDCSGNTC generiert ist oder nicht. Ist die Anweisung mit T-PROT=(SOCKET,*ANY | *HTTP) generiert, dann muss bei SIGNON-TAC der Wert *NONE angegeben werden, falls für die UTM-Anwendung der TAC KDCSGNTC generiert ist.
tacname	Name des Vorgangs-TACs, über den der Anmelde-Vorgang gestartet wird. Der Transaktionscode tacname muss mit einer TAC-Anweisung generiert werden. In der TAC-Anweisung dürfen Sie für den Transaktionscode die folgenden Standardeinstellungen nicht verändern: API = KDCS, CALL = FIRST oder BOTH, ENCRYPTION-LEVEL = NONE, PGWT = NO, TACCLASS = 0, TYPE = D, keine Einschränkung der Zugriffsrechte, d.h. die Operanden ACCESS-LIST und LOCK dürfen nicht angegeben werden Für UPIC-Partner wird der Anmelde-Vorgang nur dann gestartet, wenn zusätzlich in der SIGNON-Anweisung UPIC=YES generiert ist. Für UPIC-Partner wird der Anmelde-Vorgang nicht beim Aufbau der Verbindung gestartet, sondern vor dem Start einer UPIC-Conversation (siehe auch SIGNON-Anweisung, Parameter OMIT-UPIC-SIGNOFF= im Abschnitt "SIGNON - Anmeldeverfahren steuern"). Für LU6.1-Partner wird kein Anmelde-Vorgang gestartet. tacname darf keinem Programm zugewiesen sein (Operand PROGRAM der TAC-Anweisung), das in einem mit LOAD-MODE=ONCALL generierten Lademodul liegt. Standard: KDCSGNTC, sofern in der Anwendung generiert (KDCSGNTC = Standard-Anmelde-Vorgang; generiert mit einer TAC-Anweisung) in allen anderen Fällen: *NONE    =====> Test: Fehler? ACHTUNG! Für Kommunikationspartner, die Verbindungen zur UTM-Anwendung über den primären Anwendungsnamen aufbauen (generiert in MAX APPLINAME=), kann der Anmelde-Vorgang ausschließlich über den Transaktionscode KDCSGNTC generiert werden.
T-PROT=	gibt das Transportprotokoll an, das auf den Verbindungen zu Partner-Anwendungen verwendet werden soll, die über diesen Anwendungsnamen aufgebaut werden.
NEA	Es soll ein NEA-Transportprotokoll verwendet werden. Standard: NEA
ISO	Es soll ein ISO-Transportprotokoll verwendet werden. Es hängt von der Generierung des Transportsystems ab, ob eine ISO-Transportverbindung zu dieser Anwendung aufgebaut werden kann und welches Transportprotokoll letztendlich verwendet wird. Da bei ISO-Transportverbindungen parallele Verbindungen erlaubt sind, diese jedoch von openUTM nicht unterstützt werden, akzeptiert openUTM im Contention-Fall die Verbindung des Contention Winners (CON) bzw. des Partners mit dem lexikographisch kleineren Namenspaar - ptermname, Prozessorname - (PTERM-Anweisung).
RFC1006	Es soll als Transportprotokoll TCP/IP mit dem Konvergenzprotokoll RFC1006 verwendet werden. RFC1006 ist auf BS2000-Systemen synonym zu T-PROT=ISO. Für die Kommunikation mit openUTM auf Unix-, Linux- und Windows-Systemen muss T-PROT=RFC1006 bzw. T-PROT=ISO verwendet werden.
SOCKET	Es soll native TCP/IP als Transportprotokoll verwendet werden, d.h. die Kommunikation soll über die Socket-Schnittstelle erfolgen. Wenn Sie T-PROT=SOCKET angeben, dann müssen Sie im Operanden LISTENER-PORT eine Portnummer definieren. Näheres dazu finden Sie im Abschnitt "Adressinformationen bereitstellen". Zusammen mit dem Wert SOCKET kann in Sub-Parametern die Protokollausprägung spezifiziert werden, die für diese Socket-Verbindung verwendet werden soll.
*USP	Auf Verbindungen dieses Zugriffspunkts soll das UTM-Socket-Protokoll verwendet werden. *USP ist der Standardwert
*HTTP	Auf Verbindungen dieses Zugriffspunkts soll das HTTP-Protokoll verwendet werden.
*ANY	Auf Verbindungen dieses Zugriffspunkts werden sowohl das UTM-Socket-Protokoll als auch das HTTP-Protokoll unterstützt. Bei dieser Generierung bestimmt sich das Protokoll der Verbindung aus dem Protokolltyp der ersten empfangene Nachricht.
*SECURE	Wird zusätzlich als weiterer Sub-Parameter SECURE angegeben, dann erfolgt die Kommunikation auf diesen Verbindungen unter Verwendung von TLS über den Secure Socket Layer.  Ist in BS2000-Systemen für eine Anwendung SECURE angegeben, dann wird von UTM ein zusätzlicher ENTER-Prozess mit einem Reverse Proxy für diese Anwendung gestartet. Aufgabe dieses Proxy-Prozesses ist es, SSL-Verbindungen für die UTM-Anwendung entgegen zu nehmen und an die UTM-Anwendung durchzureichen. UTM übergibt an den Reverse Proxy Prozess maximal drei Listener-Port Nummern. Das bedeutet, dass für eine UTM(BS2000) Anwendung bei maximal drei BCAMAPPL-Anweisungen das Attribut SECURE angegeben werden sollte. Werden für eine Anwendung mehr als drei BCAMAPPL-Anweisungen mit dem Attribut SECURE benötigt, dann muss der Anwender selbst eine Start-Prozedur für den Reverse Proxy Prozess erstellen und den Prozess manuell starten. Voraussetzung zum Start des Reverse Proxy Prozesses ist, dass beim Start der Anwendung eine Jobvariable mit dem Basisnamen der KDCFILE katalogisiert ist. Zur Nutzung einer solchen Jobvariablen und des Reverse Proxy Prozesses im Allgemeinen siehe die Beschreibung im Handbuch "Einsatz von UTM-Anwendungen in BS2000-Systemen" im Kapitel "UTM-Anwendungen starten".
USER-AUTH =	Mit dem Parameter USER-AUTH wird festgelegt, welchen Authentisierungsmechanismus HTTP-Clients für diese Anwendung verwenden müssen. Der Wert, der hier für diesen Parameter gesetzt wird, gilt für alle HTTP-Nachrichten, die über diesen Anwendungsnamen empfangen werden, und deren Path-Angabe nicht über eine HTTP-DESCRIPTOR Anweisung auf einen TAC abgebildet wird. Für letzt genannte Anwendungsfälle wirkt der Parameter USER-AUTH der Anweisung HTTP-DESCRIPTOR. Wenn die UTM-Anwendung ohne User generiert ist, dann darf für USER-AUTH nur der Wert *NONE angegeben werden.
*BASIC	Zur Übergabe von Authentisierungsdaten soll das Basic-Authentication Scheme aus RFC 2617 verwendet werden. Dabei werden UserId und Passwort durch Doppelpunkt getrennt und Base64-codiert im Authorization Header eines HTTP-Requests übergeben. Ist für einen HTTP-Request durch die Generierung Basic-Authorization verlangt, aber im HTTP-Request ist kein Authorization Header enthalten, dann fordert UTM Authentisierungsdaten mittels einer Response mit Status-Code 401 Unauthorized an.
*NONE	Ist *NONE angegeben, dann muss der Client keine Authentisierungsdaten übergeben. UTM verwendet für einen solchen Request den Verbindungs-User, falls der Client nicht von sich aus Authentisierungs­information in dem HTTP-Request mitschickt. Standard: *NONE

BCAMAPPL-Anweisung auf Unix-, Linux- und Windows-Systemen

Auf Unix-, Linux- und Windows-Systemen dienen die Operanden appliname, LISTENER-PORT (TCP/IP-Portnummer), T-PROT (verwendete Transportprotokolle) und TSEL-FORMAT (Formatindikator) zur Angabe der Adresse.

BCAMAPPL

appliname  [ ,LISTENER-ID=number ]  [ ,LISTENER-PORT=number ]  [ ,SIGNON-TAC={ *NONE | tacname } ]  [ ,T-PROT={ RFC1006 | SOCKET |              (SOCKET [,*ANY | *USP | *HTTP] [,SECURE])} ]  [ ,USER-AUTH = *NONE | *BASIC]]   [ ,TSEL-FORMAT={ T | E | A } ]

appliname	Zusätzlicher Name der UTM-Anwendung. appliname kann max. 8 Zeichen lang sein. appliname darf nicht mit den Anwendungsnamen identisch sein, die Sie in ACCESS-POINT...,TRANSPORT-SELECTOR= angeben. Außerdem muss sich der Name auch vom Anwendungsnamen unterscheiden, den Sie im Operanden BCAMAPPL der CLUSTER-Anweisung angegeben haben. appliname muss auf dem lokalen Rechner eindeutig sein. KDCDEF erzeugt aus appliname einen T-Selektor für das Transportsystem. Der T-Selektor ist Bestandteil der Transportadresse der Anwendung, über die diese von Partner-Anwendungen beim Verbindungsaufbau adressiert wird. Ausnahme: Bei T-PROT=SOCKET ist appliname nur UTM-intern von Bedeutung, z.B. für die Administration. Der Name muss nur innerhalb der Anwendung eindeutig sein. Unix-, Linux- und Windows-Systeme Pro appliname können zu einer Zeit maximal 1000 Verbindungen aufgebaut werden.
LISTENER-ID=	nummer  ordnet dem Anwendungsnamen eine Listener-ID als Verwaltungsinformation  zu. Listener-IDs können Sie für Anwendungsnamen und Zugriffspunkte angeben. Siehe dazu auch die ACCESS-POINT-Anweisung. Über die Listener-IDs können Sie die Netzanbindungen der Zugriffspunkte auf verschiedene Netzprozesse verteilen. Alle Verbindungen eines Zugriffspunktes werden von demselben Netzprozesses verwaltet. BCAMAPPL-Namen mit T-PROT=SOCKET (Kommunikation über die Socket-Schnittstelle) bilden einen eigenen Nummernkreis, d.h. die Zugriffspunkte für die Kommunikation über die Socket-Schnittstelle werden grundsätzlich über andere Netzprozesse verwaltet als die Zugriffspunkte für andere Transportprotokolle. Geben Sie keine Listener-ID an, dann nimmt openUTM als Listener-ID den Wert 0 an. Alle Verbindungen ohne Listener-ID, die nicht über die Socket-Schnittstelle aufgebaut werden, werden in einem Netzprozess zusammengefasst und alle Verbindungen ohne Listener-ID, die über die Socket-Schnittstelle aufgebaut werden, werden in einem anderen Netzprozess zusammengefasst. Standardwert: 0 Minimalwert: 0 Maximalwert: 65535
LISTENER-PORT=	number  Portnummer der UTM-Anwendung. Es sind alle Portnummern zwischen 1 und 65535 erlaubt. Bei T-PROT=RFC1006 und OPTION CHECK-RFC1006=YES sowie bei T-PROT=SOCKET muss bei LISTENER-PORT eine Portnummer angegeben werden. In allen anderen Fällen ist der Standardwert 0 (keine Portnummer). Bei der Kommunikation über die Socket-Schnittstelle (SOCKET) kann eine Portnummer nur einmal pro Prozessor zum Horchen auf Verbindungsaufbauten verwendet werden. Wenn der Standardwert verwendet wird (Portnummer 0), wird intern mit der Portnummer gearbeitet, die PCMX als Standard vergibt. Dies kann zu Konflikten führen, wenn z.B. der Port durch unterschiedliche Anwendungen genutzt wird.
SIGNON-TAC=	Gibt an, ob für Verbindungen, die über den Anwendungsnamen appliname (=Transportsystemzugangspunkt) aufgebaut werden, ein Anmelde-Vorgang gestartet werden soll oder nicht. Soll ein Anmelde-Vorgang gestartet werden, dann müssen Sie den Namen des Transaktionscodes angeben, über den der Anmelde-Vorgang gestartet wird.
*NONE	Für Verbindungen, die über den Anwendungsnamen appliname zu der UTM-Anwendung aufgebaut werden, soll kein Anmelde-Vorgang gestartet werden, unabhängig davon, ob der TAC KDCSGNTC generiert ist oder nicht. Ist die Anweisung mit T-PROT=(SOCKET,*ANY | *HTTP) generiert, dann muss bei SIGNON-TAC der Wert *NONE angegeben werden, falls für die UTM-Anwendung der TAC KDCSGNTC generiert ist.
tacname	Name des Vorgangs-TACs, über den der Anmelde-Vorgang gestartet wird. Der Transaktionscode tacname muss mit einer TAC-Anweisung generiert werden. In der TAC-Anweisung dürfen Sie für den Transaktionscode die folgenden Standardeinstellungen nicht verändern: API = KDCS, CALL = FIRST oder BOTH, ENCRYPTION-LEVEL = NONE, PGWT = NO, TACCLASS = 0, TYPE = D, keine Einschränkung der Zugriffsrechte, d.h.die Operanden ACCESS-LIST und LOCK dürfen nicht angegeben werden Für UPIC-Partner wird der Anmelde-Vorgang nur dann gestartet, wenn zusätzlich in der SIGNON-Anweisung UPIC=YES generiert ist. Für UPIC-Partner wird der Anmeldevorgang nicht beim Aufbau der Verbindung gestartet, sondern vor dem Start einer UPIC-Conversation, siehe auch SIGNON-Anweisung, Parameter OMIT-UPIC-SIGNOFF im Abschnitt "SIGNON - Anmeldeverfahren steuern". Für LU6.1-Partner wird kein Anmelde-Vorgang gestartet. Standard: KDCSGNTC, sofern in der Anwendung generiert (KDCSGNTC = Standardanmelde-Vorgang; generiert mit einer TAC-Anweisung) in allen anderen Fällen: *NONE ACHTUNG! Stimmt der angegebene Anwendungsname in appliname mit dem pimären Anwendungsnamen (generiert in MAX APPLINAME=) überein, dann dürfen Sie für SIGNON-TAC= nur KDCSGNTC (Standardanmelde-Vorgang), *NONE oder ein Leerzeichen angeben.
T-PROT=	Adressformate der T-Selektoren in der Transportadresse Folgende Adressformate können Sie bei T-PROT angeben:
RFC1006	Adressformat RFC1006 Näheres zum Adressformat RFC1006 siehe Abschnitt "Dokumentation zu PCMX" (openUTM-Dokumentation). Standard: RFC1006
SOCKET	Die Kommunikation erfolgt über die Socket-Schnittstelle. Neben T-PROT=SOCKET, LISTENER-PORT und appliname müssen keine weiteren Angaben zur Adresse gemacht werden. Näheres zum Adressformat SOCKET finden Sie in Abschnitt "Adressinformationen bereitstellen". Zusammen mit dem Wert SOCKET kann in Sub-Parametern die Protokollausprägung spezifiziert werden, die für diese Socket-Verbindung verwendet werden soll.
*USP	Auf Verbindungen dieses Zugriffspunkts soll das UTM-Socket-Protokoll verwendet werden. *USP ist der Standardwert
*HTTP	Auf Verbindungen dieses Zugriffspunkts soll das HTTP-Protokoll verwendet werden.
*ANY	Auf Verbindungen dieses Zugriffspunkts werden sowohl das UTM-Socket-Protokoll als auch das HTTP-Protokoll unterstützt. Bei dieser Generierung bestimmt sich das Protokoll der Verbindung aus dem Protokolltyp der ersten empfangene Nachricht.
*SECURE	Wird zusätzlich als weiterer Sub-Parameter SECURE angegeben, dann erfolgt die Kommunikation auf diesen Verbindungen unter Verwendung von TLS über den Secure Socket Layer.
USER-AUTH =	Mit dem Parameter USER-AUTH wird festgelegt, welchen Authentisierungsmechanismus HTTP-Clients für diese Anwendung verwenden müssen. Der Wert, der hier für diesen Parameter gesetzt wird, gilt für alle HTTP-Nachrichten, die über diesen Anwendungsnamen empfangen werden, und deren Path-Angabe nicht über eine HTTP-DESCRIPTOR Anweisung auf einen TAC abgebildet wird. Für letzt genannte Anwendungsfälle wirkt der Parameter USER-AUTH an der Anweisung HTTP-DESCRIPTOR. Wenn die UTM-Anwendung ohne User generiert ist, dann darf für USER-AUTH nur der Wert *NONE angegeben werden.
*BASIC	Zur Übergabe von Authentisierungsdaten soll das Basic-Authentication Scheme aus RFC 2617 verwendet werden. Dabei werden UserId und Passwort durch Doppelpunkt getrennt und Base64-codiert im Authorization Header eines HTTP-Request übergeben.Ist für einen HTTP-Request durch die Generierung Basic-Authorization verlangt, aber im HTTP-Request ist kein Authorization Header enthalten, dann fordert UTM Authentisierungsdaten mittels einer Response mit Status-Code 401 Unauthorized an.
*NONE	Ist *NONE angegeben, dann muss der Client keine Authentisierungsdaten übergeben. UTM verwendet für einen solchen Request den Verbindungs-User, falls der Client nicht von sich aus Authentisierungs­information in dem HTTP-Request mitschickt. Standard: *NONE
TSEL-FORMAT=	Formatindikator der T-Selektoren, die aus appliname erzeugt werden sollen. Der Formatindikator gibt die Codierung des T-Selektors im Transportprotokoll an. Nähere Informationen siehe Abschnitt "Dokumentation zu PCMX" (openUTM-Dokumentation).
T	TRANSDATA-Format (Codierung erfolgt in EBCDIC). In diesem Fall muss appliname genau 8 Zeichen lang sein und darf keine Kleinbuchstaben enthalten.
E	EBCDIC-Zeichenformat
A	ASCII-Zeichenformat Standard:     T    wenn der Zeichenvorrat von appliname dem TRANSDATA-Format entspricht     E    sonst Für den Betrieb über RFC1006 wird jedoch empfohlen, explizit einen Wert für TSEL-FORMAT anzugeben.