UTMD - Anwendungsparameter für verteilte Verarbeitung festlegen

Mit der UTMD-Anweisung werden für die verteilte Verarbeitung anwendungsweit gültige Werte festgelegt. Eine UTMD-Anweisung ist nur erforderlich für Anwendungen, die das LU6.1- oder das OSI TP-Protokoll zur Kommunikation verwenden.

Die UTMD-Anweisung darf nur einmal angegeben werden.

Wenn Sie in Ihrer Anwendung das OSI TP-Protokoll nutzen, dann können Sie in der UTMD-Anweisung den Application Process Title (APT) der Anwendung angeben. Der APT wird von einigen heterogenen Partnern benötigt, die eine andere Ausprägung des OSI TP-Protokolls unterstützen. Diese Anwendungen erwarten die Angabe des Application Process Title beim Verbindungsaufbau.

Der APT bildet zusammen mit jedem Application Entity Qualifier (AEQ), den Sie einem Zugriffspunkt (Access Point) Ihrer Anwendung zugeordnet haben, einen im OSI-Netz eindeutigen Application Entity Title (AET). Mit ihm kann die Partner-Anwendung den Zugriffspunkt der lokalen Anwendung identifizieren, über den die Kommunikation erfolgen soll.

UTMD	[ APPLICATION-PROCESS-TITLE=object_identifier ]  [ ,CONCTIME={ time1 | ( time1,time2 ) } ]  [ ,MAXJR=%_maxjr ]  [ ,PTCTIME=time3 ]  [ ,RSET={ GLOBAL | LOCAL } ]

APPLICATION-PROCESS-TITLE=object_identifier
	(nur relevant, wenn in der Anwendung das OSI TP-Protokoll benutzt wird) Adresskomponente des Application Entity Title (AET). Der AET wird dann benötigt, wenn mit Transaktionssicherung (Commit Functional Unit) gearbeitet wird, oder wenn ein heterogener Partner einen AET für den Verbindungsaufbau erwartet. object_identifier ist der Application Process Title (APT) Ihrer Anwendung. Auch wenn er nicht von einem Standardisierungsgremium vergeben wurde, müssen Sie bei der Vergabe die bereits bestehenden Konventionen für komponente1 und komponente2 beachten. Siehe dazu Abschnitt „Application Entity Title (AET)“ im Abschnitt "OSI-Begriffe". In der Praxis ist es erforderlich, dass der angegebene object_identifier im Netz eindeutig ist. Enthält der mit einer Partner-Anwendung vereinbarte Application Context (Definition des Kommunikationspartners in der OSI-LPAP-Anweisung, Abschnitt "OSI-LPAP - OSI-LPAP-Partner für verteilte Verarbeitung über OSI TP definieren") die CCR-Syntax, dann muss ein APT angegeben werden. Ein Application Process Title besteht aus mindestens 2 und maximal aus 10 Komponenten. Er wird angegeben in der Form: (komponente1,komponente2,...,komponente10) Für die Komponenten werden positive ganze Zahlen vergeben. Bestimmten Zahlen einzelner Komponenten sind symbolische Namen zugeordnet. Sie können statt der Zahlen auch diese Namen angeben. Bei einem Application Process Title ist sowohl die Position der einzelnen Komponenten in der Klammer als auch die Anzahl der Komponenten relevant, z.B. bezeichnen (1,2,3), (1,2,3,0,0) und (0,1,2,3,0) verschiedene Application Process Titles. openUTM und die OSI-Norm erlauben für komponente1 nur die Werte bzw. die symbolischen Namen: 0 oder CCITT 1 oder ISO 2 oder JOINT-ISO-CCITT Die für komponente2 erlaubten Werte sind abhängig vom Wert der Komponente komponente1. Ist komponente1=0 oder 1, dann sind für komponente2 Werte zwischen 0 und 39 erlaubt (0 <= komponente2 <= 39). Ist komponente1=2, dann sind für komponente2 Werte zwischen 0 und 67108863 (226-1) erlaubt (0 <= komponente2 <= 67108863). Für alle anderen Komponenten sind Werte zwischen 0 und 67108863 (226-1) erlaubt. openUTM führt keine Überprüfung durch, ob ein von einem Standardisierungsgremium registrierter Application Process Title angegeben wird. Hinweis zu UTM-Cluster-Anwendungen auf Unix-, Linux- und Windows-Systemem Für UTM-Cluster-Anwendungen wird der APT der einzelnen Knoten-Anwendungen knoten-spezifisch modifiziert, um die Eindeutigkeit des AET zu gewährleisten. Besteht der APT aus weniger als 10 Elementen, dann wird der APT beim Start einer Knoten-Anwendung um den Index des eigenen Knotens ergänzt. Der Index eines Knotens wird durch die Reihenfolge der CLUSTER-NODE-Anweisungen bei der Generierung festgelegt. Beispiel: Wird als APT (1,2,3) generiert und besitzt die UTM-Cluster-Anwendung zwei Knoten-Anwendungen, dann lautet der APT zur Ablaufzeit wie folgt: (1,2,3,1) für Knoten 1 (= erste CLUSTER-NODE-Anweisung) und (1,2,3,2) für Knoten 2 (= zweite CLUSTER-NODE-Anweisung) Besteht der generierte APT bereits aus 10 Elementen, dann bleibt der APT für alle Knoten-Anwendungen unverändert. In diesem Fall kann es bei Kopplungen mit OSI-TP-Implementierungen anderer Hersteller zu Problemen kommen, da der AET nicht eindeutig ist.
CONCTIME=	(connection control time)
time1	Zeit in Sekunden zur Überwachung des Aufbaus einer Session (LU6.1) bzw. Association (OSI TP). Wenn die Session bzw. Association nicht innerhalb der angegebenen Zeit aufgebaut wird, baut openUTM die Transportverbindung ab. Damit wird verhindert, dass eine Transportverbindung wegen eines misslungenen Aufbaus einer Session bzw. Association blockiert bleibt. Das ist möglich, wenn eine zum Aufbau erforderliche Nachricht verloren geht. Bei CONCTIME=0 für LU6.1 wird der Aufbau nicht überwacht. Bei CONCTIME=0 für OSI TP wird die Zeitüberwachung intern auf 60 Sek. gesetzt. Standard: 0 Minimalwert: 0 Maximalwert: 32767
time2	Zeit in Sekunden, die beim Übertragen einer asynchronen Nachricht maximal auf eine Quittung von der Partner-Anwendung gewartet wird. Nach Ablauf der angegebenen Zeit baut openUTM die Transportverbindung ab. Der Auftrag geht nicht verloren. Mit der Überwachung wird vermieden, dass eine Verbindung nicht weiter genutzt werden kann, weil eine Quittung verloren ging, oder ein Verbindungsverlust nicht vom Transportsystem an openUTM gemeldet wurde. Der Wert 0 bedeutet, dass keine Überwachung durchgeführt wird. Standard: 0 Minimalwert: 0 Maximalwert: 32767
MAXJR=	%_maxjr (maximal number of job receivers) legt fest, wieviele Auftragnehmer-Vorgänge maximal zu einem Zeitpunkt in der lokalen Anwendung addressiert sein dürfen. Diese Zahl entspricht den gleichzeitig möglichen aktiven APRO-Aufrufen. Der %-Wert bezieht sich auf die Anzahl der generierten Sessions und Associations (Anzahl LSES-Anweisungen für das Protokoll LU6.1 + Summe der bei den OSI-LPAP-Anweisungen angegebenen Anzahl paralleler Verbindungen; Operand ASSOCIATIONS). Der %-Wert muss zwischen 0 und 200 liegen. Ein Wert > 100 wird angegeben, damit APRO-Aufrufe, die vor der Sessionbelegung abgesetzt werden, in eine Tabelle eingetragen werden können. Standard: 100 d.h. die maximale Anzahl der zu einer Zeit aktiven Auftragnehmer- Vorgänge ist gleich der Anzahl der Sessions und Associations. Minimalwert: 0 Maximalwert: 200
PTCTIME=	time3 (prepare to commit) legt die Zeit in Sekunden fest, die ein Server-Vorgang maximal im Zustand PTC (Transaktionsstatus P) auf eine Quittung vom Auftraggeber wartet. Nach Ablauf der Zeit wird die Verbindung zum Auftraggeber abgebaut, die Transaktion im Server-Vorgang zurückgesetzt und der Vorgang beendet. Dies kann zu einem inkonsistenten Datenbestand führen, falls die Transaktion in der Partneranwendung vorgesetzt wird (Mismatch). Bei PTCTIME=0 wird beliebig lange auf eine Quittung gewartet. Wird in time3 ein Wert > 0 angegeben, dann ignoriert openUTM diesen Wert, wenn ein KDCSHUT WARN oder GRACE gegeben wurde. In diesem Fall wählt openUTM die Wartezeit so, dass die Transaktion zurückgesetzt wird, bevor die Anwendung beendet wird, um eine abnormale Anwendungsbeendigung mit ENDPET möglichst zu vermeiden. Standard: Wert bei MAX ...,TERMWAIT=time für die Wartezeit nach PEND KP. Minimalwert: 0 Maximalwert: 32767
RSET=	legt bei der verteilten Transaktionsverarbeitung fest, wie sich das Rücksetzen einer lokalen Transaktion auf die verteilte Transaktion auswirkt. Eine lokale Transaktion kann zurückgesetzt werden: durch einen RSET-Aufruf aus einem Teilprogramm oder durch das Rücksetzen einer Datenbanktransaktion, die an der lokalen Transaktion beteiligt ist.
GLOBAL	Nach dem Rücksetzen einer lokalen Transaktion muss das Teilprogramm so beendet werden, dass openUTM die verteilte Transaktion zurücksetzt. Standard: GLOBAL
LOCAL	Das Rücksetzen einer lokalen Transaktion hat keinen Einfluss auf die verteilte Transaktion. Es kann zu Inkonsistenzen in den verteilten Datenbeständen kommen, wenn einige der an einer verteilten Transaktion beteiligten lokalen Transaktionen zurückgesetzt und andere abgeschlossen werden. Wird RSET=LOCAL angegeben, wird die globale Datenkonsistenz nicht mehr von den beteiligten Systemkomponenten garantiert. Sie liegt dann in der Verantwortung der Anwendungsteilprogramme. Sie müssen entscheiden, in welchen Situationen die verteilte Transaktion noch sinnvoll beendet werden kann und in welchen Situationen sie zurückgesetzt werden muss.