PEND Beenden eines Teilprogramms

Mit dem Aufruf PEND (program end) beenden Sie ein Teilprogramm. Jedes UTM-Teilprogramm, einschließlich der Event-Services (BADTACS, MSGTAC, SIGNON) muss über den PEND-Aufruf verlassen werden (Ausnahme: Event-Exits). Je nach Art des Programms wird eine der Varianten des PEND-Aufrufs verwendet.

Bei verteilter Verarbeitung müssen die PEND-Aufrufe von Auftraggeber-Vorgang und Auftragnehmer-Vorgang aufeinander abgestimmt werden, siehe Kapitel „Programmaufbau bei verteilter Verarbeitung".

Die Abkürzungen in Feld KCOM sind aus folgenden Begriffen entstanden:

PS	program and sign(on)
PA/PR	program
KP	keep
RE	return
SP	synchronization point
FI	finish
FC	finish and continue
RS	reset
ER	error
FR	finish and reset

Versorgen des 1. Parameters (KDCS-Parameterbereich)

Die folgende Tabelle zeigt die verschiedenen Möglichkeiten und die dafür notwendigen Angaben im KDCS-Parameterbereich.

Funktion des Aufrufs	Einträge im KDCS-Parameterbereich
	KCOP	KCOM	KCRN
Anmelde-Vorgang nach Berechtigungsprüfung im Folge-Teilprogramm fortsetzen	"PEND"	"PS"	TAC des Folge-Teilprogramms
Verarbeitungsschritt im Folge-Teilprogramm fortsetzen	"PEND"	"PA"/"PR"	TAC des Folge-Teilprogramms
Verarbeitungsschritt beenden ohne Transaktionsende	"PEND"	"KP"	TAC des Folge-Teilprogramms
Verarbeitungsschritt beenden mit Transaktionsende	"PEND"	"RE"	TAC des Folge-Teilprogramms
Transaktion beenden; Verarbeitungsschritt fortsetzen	"PEND"	"SP"	TAC des Folge-Teilprogramms
Verarbeitungsschritt, Transaktion und Vorgang beenden	"PEND"	"FI"	—
Transaktion + Vorgang beenden; Verarbeitungsschritt im angeketteten Vorgang fortsetzen	"PEND"	"FC"	TAC des Folge-Teilprogramms
Transaktion zurücksetzen	"PEND"	"RS"	Leerzeichen
Vorgang abbrechen, die Transaktion zurücksetzen, Speicherabzug (Dump) anfordern und Anwendungsprogramm neu starten	"PEND"	"ER"	—
Vorgang abbrechen und die Transaktion zurücksetzen, kein Speicherabzug, kein Neustart des Anwendungsprogramms	"PEND"	"FR"	Leerzeichen

Bei KCOM = PS/FC/SP/RS müssen alle nicht verwendeten Felder des KDCS-Parameterbereichs mit binär null versorgt werden.

Versorgen der Parameter
Feldname im KDCS-Parameterbereich	Inhalt
KCOP	"PEND"
KCOM	"PS"/"PA"/"PR"/"KP"/"RE"/"FI"/"FC"/"RS"/"ER"/"FR"/"SP"
KCRN	Folge-Transaktionscode/Leerzeichen/ —

KDCS-Aufruf
1. Parameter	2. Parameter
KDCS-Parameterbereich	—

C/C++-Makroaufrufe
Makronamen	Parameter
KDCS_PENDER/KDCS_PENDFI/KDCS_PENDFR/KDCS_PENDRS	()
KDCS_PENDFC/KDCS_PENDKP/KDCS_PENDPA/KDCS_PENDPR/KDCS_PENDPS/KDCS_PENDRE/KDCS_PENDSP	(kcrn)

Rückgaben von openUTM
Feldname im KB-Rückgabebereich	Inhalt
KCRCCC	Returncode
KCRCDC	interner Returncode

Im KDCS-Parameterbereich tragen Sie für den PEND-Aufruf ein:

KCOP

im Feld v den Operationscode PEND.

KCOM

im Feld KCOM die Variante des PEND-Aufrufs:

• PS: Fortsetzung des Anmelde-Vorgangs in einem Folgeprogramm

• PR / PA: Fortsetzung des Verarbeitungsschritts in einem Folgeprogramm

• KP: Ende des Verarbeitungsschritts ohne Transaktionsende

• RE: Ende des Verarbeitungsschritts mit Transaktionsende

• SP: Ende der Transaktion, Fortsetzung des Verarbeitungsschritts in einem Folgeprogramm

• FI: Vorgangsende

• FC: Vorgangsende mit Vorgangs-Kettung

• RS: Transaktion wird zurückgesetzt (mit anschließendem Vorgangs-Wiederanlauf, wenn ein Aufsetzpunkt existiert).

• ER: Vorgangsende wegen Fehler. Der Vorgang wird abnormal beendet, die Transaktion zurückgesetzt und ein DUMP erzeugt.

• FR: Vorgangsende wegen Fehler. Der Vorgang wird abnormal beendet und die Transaktion zurückgesetzt (ohne DUMP!).

KCRN

im Feld KCRN je nach Variante

• bei PEND KP/RE:
  den TAC des Folge-Teilprogramms in dem nach dem Empfang der nächsten Eingabenachricht die Verarbeitung fortgesetzt werden soll.

• bei PEND PA/PR/PS/SP:
  den TAC des Folge-Teilprogramms in dem die Verarbeitung des gleichen Verarbeitungsschritts fortgesetzt werden soll.

• bei PEND RS/FR:
  Leerzeichen

• bei PEND ER/FI:
  irrelevant.

Beim KDCS-Aufruf geben Sie an:

1. Parameter

als 1. Parameter: Die Adresse des KDCS-Parameterbereichs.

Makronamen

Wie Sie Makroaufrufe für C/C++ nutzen, ist in Abschnitt „C/C++-Makroschnittstelle" ausführlich beschrieben.

openUTM gibt zurück:

KCRCCC

im Feld KCRCCC den KDCS-Returncode, siehe unten.

KCRCDC

im Feld KCRCDC den internen Returncode von openUTM (siehe openUTM-Handbuch „Meldungen, Test und Diagnose“).

KDCS-Returncodes im Feld KCRCCC beim PEND-Aufruf

Diese Returncodes sind nur dem DUMP zu entnehmen:

000	Die Operation wurde ausgeführt (bei angefordertem PEND ER).
70Z	Die Operation PEND konnte nicht ausgeführt werden (System- bzw. Generierungsfehler, Deadlock, Timeout), siehe KCRCDC.
71Z	In diesem Teilprogrammlauf wurde noch kein INIT gegeben.
72Z	KCOM enthält eine ungültige Operationsmodifikation bei Aufruf im MSGTAC-Programm, im Anmelde-Vorgang, außerhalb des Anmelde-Vorgangs, im Server-Vorgang, im Asynchron-Vorgang oder die Operationsmodifikation steht im Widerspruch zur Datenbanktransaktion, zum verwendeten Kommunikationsprotokoll, zum Status des Anmelde-Vorgangs zum Warten auf eine DGET-Nachricht
74Z	das Feld KCRN enthält einen Wert, der kein TAC oder kein Folge-TAC ist, der Benutzer ist nicht berechtigt, den TAC zu verwenden, ein Wechsel zwischen Dialog- und Asynchron-TAC liegt vor, ein Wechsel zwischen Teilprogrammen mit KDCS- und X/OPEN- API liegt vor, bei einem PEND RS,FR ist KCRN nicht mit SPACES belegt beim Warten auf eine DGET-Nachricht ist der in KCRN angegebene TAC in keiner TAC-Klasse
81Z	Die Angabe in KCRN beim PEND PA/PR/FC/SP/PS (TAC des Folgeprogramms) steht im Widerspruch zur Angabe in KCRN beim MPUT (z.B. MPUT TAC1 und PEND xx TAC2).
82Z	Die Angabe in KCOM oder KCRN des PEND widerspricht den Angaben beim vorausgehenden MPUT: MPUT mit KCRN=Leerzeichen bei PEND PA/PR/PS/SP/FC MPUT mit KCRN=TAC bei PEND KP/RE/FI/ER/FR MPUT mit KCRN=RESET-ID und kein PEND RS MPUT mit KCRN=Vorgangs-Id bei PEND PA/PR/FI/ER/FR. MPUT mit KCRN=Leerzeichen an einen HTTP-Client und kein PEND FI
83Z	MPUT Aufruf fehlt: Vor einem PEND KP/RE/FI/ER/FR hat das Dialog-Programm keinen MPUT gegeben vor einem PEND RS in einer Folgetransaktion wurde keine Rücksetznachricht mit MPUT RM gesendet vor einem mit PEND FI beendeten Teilprogramm in einem Anmelde-Vorgang mit Vorgangs-Wiederanlauf wurde kein MPUT PM gegeben.
86Z	Fehlender KDCS-Aufruf beim Message Queuing: Auftrags-Komplex beim PEND-Aufruf nicht abgeschlossen zu einem DPUT NI-Aufruf war kein Auftrag erzeugt worden an einen mit APRO AM adressierten Vorgang war kein Asynchron-Auftrag gesendet worden.
87Z	Der PEND-Aufruf steht im Widerspruch zum Transaktions- oder Vorgangs-Status eines entfernten Vorgangs.
89Z	Der Inhalt nicht verwendeter Felder des KDCS-Parameterbereichs ist ungleich binär null (nur bei KCOM = PS/FC/RS/SP).

Die folgende Tabelle zeigt die PEND-Varianten und die damit verknüpften Aktionen.

Variante	Bedeutung	Aktionen von openUTM
PS	Anmelde-Vorgang soll im Folgeprogramm fortgesetzt werden. Kein Sicherungspunkt!	Berechtigungsdaten prüfen eventuell Zwischendialog zur Abfrage von Passwort, Ausweisinformation führen. MPUT dieses Teilprogramms für das Folgeteilprogramm bereitstellen bzw. auf Pagepool sichern, wenn ein Zwischendialog notwendig ist. TAC des Folgeteilprogramms aus dem Feld KCRN übernehmen und Folgeprogramm sofort oder nach Ende des Zwischendialogs starten.
PA oder PR	Verarbeitungsschritt soll im Folgeprogramm fortgesetzt werden. Die Transaktion bleibt offen. Kein Sicherungspunkt!	MPUT dieses Teilprogramms für das Folgeprogramm bereitstellen. TAC des Folgeprogramms aus dem Feld KCRN übernehmen. Bei TAC-Klassensteuerung wird das Folge-Teilprogramm sofort gestartet, wenn es zu derselben TAC-Klasse gehört, ansonsten wird es verzögert gestartet. Soll auf eine DGET-Nachricht gewartet werden, startet openUTM das Folgeteilprogramm erst dann, wenn für diese Queue eine Nachricht eintrifft oder erneut in die Queue gestellt wird (Redelivery) oder wenn die maximale Wartezeit abgelaufen ist oder wenn die Queue gelöscht wurde (siehe DGET-Aufruf).
SP	Ende der Transaktion. Verarbeitungsschritt soll aber im nächsten Teilprogramm fortgesetzt werden. Sicherungspunkt!	DB-Transaktion schließen DPUT, FPUT, LPUT, PTDA, SPUT und SREL der Transaktion ausführen. In der ersten Transaktion eines Asynchron-Vorgangs FGET-Nachricht löschen. Mit DGET verarbeitete Nachrichten aus ihrer Queue löschen. MPUT dieses Teilprogramms ausführen TAC des Folgeprogramms aus dem Feld KCRN übernehmen. Bei TAC-Klassensteuerung wird das Folge-Teilprogramm sofort gestartet, wenn es zu derselben TAC-Klasse gehört, ansonsten wird es verzögert gestartet.
KP	Ende des Verarbeitungsschritts, ohne die Transaktion zu beenden. Sie soll im nächsten Verarbeitungsschritt fortgesetzt werden. Kein Sicherungspunkt!	MPUT dieses Teilprogramms ausführen (ggf. Nachricht formatieren). ggf. Daten im KB übernehmen und dem Folgeprogramm übergeben, sobald es initialisiert wird. TAC des Folgeprogramms aus dem Feld KCRN übernehmen und Folgeprogramm starten, sobald die nächste Nachricht kommt.
RE	Ende des Verarbeitungsschritts und gleichzeitiges Ende der Transaktion. Der Vorgang soll in einem Folgeprogramm fortgesetzt werden. Sicherungspunkt!	DB-Transaktion schließen DPUT, FPUT, LPUT, PTDA, SPUT und SREL der Transaktion ausführen. In der ersten Transaktion eines Asynchron-Vorgangs FGET-Nachricht löschen. Mit DGET verarbeitete Nachrichten aus ihrer Queue löschen. MPUT dieses Teilprogramms ausführen (ggf. Nachricht formatieren). Betriebsmittel freigeben TAC des Folgeteilprogramms aus dem Feld KCRN übernehmen und Folgeteilprogramm starten, sobald die nächste Nachricht kommt. ggf. Daten im KB-Programmbereich übernehmen und dem Folgeteilprogramm übergeben, sobald es initialisiert wird.
FI	Ende eines Vorgangs und Ende der Transaktion. Sicherungspunkt!	DB-Transaktion schließen DPUT, FPUT, LPUT, PTDA, SPUT und SREL (für GSSB) der Transaktion ausführen In der ersten Transaktion eines Asynchron-Vorgangs FGET-Nachricht löschen. Mit DGET verarbeitete Nachrichten aus ihrer Queue löschen. LSSBs des Vorgangs freigeben. MPUT dieses Teilprogramms ausführen (ggf. Nachricht formatieren) Betriebsmittel freigeben
FC	Ende eines Vorgangs und Ende der Transaktion, Verarbeitungsschritt soll im angeketteten Vorgang fortgesetzt werden. Sicherungspunkt!	DB-Transaktion schließen DPUT, FPUT, LPUT, PTDA, SPUT und SREL (für GSSB) der Transaktion ausführen Mit DGET verarbeitete Nachrichten aus ihrer Queue löschen. LSSBs des Vorgangs freigeben. MPUT dieses Teilprogramms an das erste Teilprogramm des angeketteten Vorgangs übergeben Betriebsmittel freigeben
RS	Rücksetzen einer Transaktion auf den letzten Sicherungspunkt	In der ersten Transaktion eines Vorgangs: UTM- und DB-Transaktion zurücksetzen Vorgang beenden (gegebenenfalls Meldung K034 an den Client) nur bei Terminals und TS-Anwendungen: letzte Ausgabenachricht des vorherigen Vorgangs ausgeben (wenn vorhanden). Asynchron-Vorgänge und Folge-Vorgänge (bei Vorgangs-Kettung) nach dem Rücksetzen erneut starten in einer Folgetransaktion eines Vorgangs: UTM- und DB-Transaktion auf den letzten Sicherungspunkt zurücksetzen und ggf. erfolgt Bildschirmwiederanlauf mit Meldung K034. das am letzten Sicherungspunkt adressierte Teilprogramm starten Rücksetznachricht an dieses Teilprogramm übergeben für alle Transaktionen eines Vorgangs: mit DGET verarbeitete Nachrichten können nochmal verarbeitet werden, wenn die in der Generierung festgelegte maximale Anzahl erneuter Zustellungen noch nicht erreicht ist. Ansonsten werden sie gelöscht oder bei Nachricht einer TAC-Queue gegebenenfalls in die Dead Letter Queue gesichert. Sind für den aktuellen TAC PGWT-Aufrufe erlaubt und der PEND RS wurde nicht vom Teilprogramm aufgerufen: Anwendungsprogramm neu starten
ER (ERror)	Ende des Vorgangs mit Speicherabzug und Neustart des Anwendungsprogramms. Rücksetzen auf letzten Sicherungspunkt (Ausnahme: MPUT)	UTM-Dump schreiben UTM- und DB-Transaktion zurücksetzen Mit DGET verarbeitete Nachrichten können nochmal verarbeitet werden, wenn die in der Generierung festgelegte maximale Anzahl erneuter Zustellungen noch nicht erreicht ist. Ansonsten werden sie gelöscht oder bei Nachricht einer TAC-Queue gegebenenfalls in die Dead Letter Queue gesichert. In der ersten Transaktion eines Asynchron-Vorgangs: Die FGET-Nachricht kann nochmal verarbeitet werden, wenn die in der Generierung festgelegte maximale Anzahl erneuter Zustellungen noch nicht erreicht ist. Ansonsten wird sie gelöscht oder gegebenenfalls in die Dead Letter Queue gesichert Speicherabzug des Anwendungsprogramms veranlassen. MPUT dieses Teilprogramms ausführen (ggf. Nachricht formatieren) Anwendungsprogramm neu starten Betriebsmittel freigeben
FR	Ende des Vorgangs, kein Speicherabzug, das Anwendungsprogramm bleibt geladen. Rücksetzen auf letzten Sicherungspunkt (Ausnahme: MPUT)	UTM- und DB-Transaktion zurücksetzen Mit DGET verarbeitete Nachrichten können nochmal verarbeitet werden, wenn die in der Generierung festgelegte maximale Anzahl erneuter Zustellungen noch nicht erreicht ist. Ansonsten werden sie gelöscht oder bei Nachricht einer TAC-Queue gegebenenfalls in die Dead Letter Queue gesichert. In der ersten Transaktion eines Asynchron-Vorgangs: Die FGET-Nachricht kann nochmal verarbeitet werden, wenn die in der Generierung festgelegte maximale Anzahl erneuter Zustellungen noch nicht erreicht ist. Ansonsten wird sie gelöscht oder gegebenenfalls in die Dead Letter Queue gesichert. MPUT dieses Teilprogramms ausführen (ggf. Nachricht formatieren) Betriebsmittel freigeben

Eigenschaften des PEND-Aufrufs

• Nach einem PEND wird nicht in das aufrufende Programm zurückverzweigt. Daher kann dort der KDCS-Rückgabecode nicht ausgewertet werden.

• Im Fehlerfall, wenn der PEND nicht ordnungsgemäß auszuführen war, ruft openUTM intern PEND ER auf.

• • Bei Dialog-Verarbeitung wird eine Meldung an den Client gesendet. Die Transaktion wird zurückgesetzt und der Vorgang beendet. Man kann einen neuen Vorgang starten.

  • Ein Asynchron-Vorgang wird abgebrochen und eine Meldung auf die System-Protokolldatei SYSLOG geschrieben.

• Führte ein anderer Aufruf zu einem KDCS-Rückgabecode >= 70Z, so ruft openUTM intern PEND ER auf.

• Ruft ein Teilprogramm in einem Dialog-Vorgang PEND ER/FR auf, muss zuvor mit MPUT eine Nachricht an den Client bzw. an den Auftraggeber-Vorgang geschickt werden - mit einer Ausnahme: Für einen OSI TP-Auftragnehmer-Vorgang bei dem KCSEND den Wert "N" enthält, gilt das nicht. Wird ein PEND ER vom openUTM intern aufgerufen (KCRCCC >= 70Z), wird eine Standardnachricht ausgegeben. Wurde jedoch bei der Kommunikation mit einem UPIC-Client mit MPUT ES eine eigene Fehlernachricht erzeugt, wird stattdessen diese Fehlernachricht an den UPIC-Client gesendet.

• Vor einem PEND RS-Aufruf in einer Folgetransaktion muss mit MPUT RM eine Rücksetznachricht gesendet werden. Ein PEND RS sollte daher nicht in der ersten Transaktion eines Vorgangs abgesetzt werden, da dann keine Rücksetznachricht gelesen werden kann. Im Gegensatz zum PEND ER wird beim PEND RS kein DUMP geschrieben.

• Wird der PEND RS-Aufruf bei Kommunikation mit einem UPIC-Client eingesetzt, muss Folgendes beachtet werden:

  Falls die vorhergehende Transaktion mit PEND SP oder PEND FC beendet wurde, wird bei einem PEND RS die lokale Transaktion zurückgesetzt und der Vorgang mit dem beim PEND SP oder PEND FC spezifizierten Folge-Teilprogramm fortgesetzt (lokaler Vorgangs-Wiederanlauf). Falls die vorhergehende Transaktion nicht mit PEND SP/FC beendet wurde und der Vorgang unter einer Benutzerkennung mit Wiederanlauf-Eigenschaft läuft, so wird der Vorgang auf den letzten Sicherungspunkt zurückgesetzt und der Dialog mit dem UPIC-Client beendet. Unter der Benutzerkennung kann ein neuer OSI TP Dialog gestartet und ein Vorgangs-Wiederanlauf angefordert werden. In allen anderen Fällen beendet openUTM den Vorgang mit PEND FR.

• Wird der PEND RS-Aufruf bei verteilter Verarbeitung über das OSI TP-Protokoll ohne COMMIT-Funktionalität eingesetzt, muss Folgendes beachtet werden:

• • bei Aufruf in einem Auftragnehmer-Vorgang: Falls die vorhergehende Transaktion mit PEND SP beendet wurde, wird bei einem PEND RS die lokale Transaktion zurückgesetzt und der Vorgang mit dem beim PEND SP spezifizierten Folge-Teilprogramm fortgesetzt (lokaler Vorgangs-Wiederanlauf). Falls die vorhergehende Transaktion nicht mit PEND SP beendet wurde und der Vorgang unter einer Benutzerkennung mit Wiederanlaufeigenschaft läuft, so wird der Vorgang auf den letzten Sicherungspunkt zurückgesetzt und der Dialog mit dem Auftraggeber beendet. Unter der Benutzerkennung kann ein neuer OSI TP Dialog gestartet und ein Vorgangs-Wiederanlauf angefordert werden.In allen anderen Fällen beendet openUTM den Vorgang mit PEND FR.

  • bei Aufruf in einem Auftraggeber-Vorgang werden alle Auftragnehmer-Vorgänge dieses Vorgangs mit PEND FR beendet.

• Wird ein PEND RS-Aufruf in einer Transaktion gegeben, die zuvor mit PGWT CM beendet wurde, dann wird der Vorgang mit PEND FR beendet.

• Wurden Nachrichten oder Nachrichtenteile, die openUTM nach dem INIT für das Programm bereithielt, im Programm mit MGET bzw. FGET nicht gelesen, gehen sie beim PEND verloren (auch beim PEND PA bzw. PR). Das Gleiche gilt bei unvollständigem Lesen einer DGET-Nachricht: die restlichen, nicht gelesenen Nachrichtenteile der Nachricht gehen verloren.

• Wurde vor einem PEND RE/SP/FI/FC eine DB-Transaktion abgeschlossen, wird die Ausführung bis zum PEND RE/SP/FI/FC verzögert.

• Ein PEND KP sperrt Betriebsmittel (LSSBs, GSSBs, TLS, ULS, ggf. Bereiche in Datenbanken) über einen Verarbeitungsschritt hinaus.

  Deshalb wird empfohlen (falls nicht mit verteilter Verarbeitung gearbeitet wird)

• • den PEND KP sparsam zu verwenden, um die Belegungszeiten für globale Betriebsmittel kurz zu halten,

  • bei Verwendung des PEND KP die globalen Betriebsmittel erst im letzten Verarbeitungsschritt zu belegen.

• Wenn die Transaktion zurückgesetzt wird, geht eine durch einen PEND KP auszuführende MPUT-Ausgabe verloren. Der Vorgang wird auf den letzten Sicherungspunkt zurückgesetzt. Es wird sofort ein Vorgangswiederanlauf durchgeführt, sofern der Benutzer noch angemeldet ist.

  Wenn der Benutzer abgemeldet wurde, z.B. weil die Verbindung zum Client verlorenging, wird beim Anmelden ein Vorgangswiederanlauf durchgeführt, sofern die Benutzerkennung (in Anwendungen ohne Benutzerkennungen der LTERM-Partner)

  mit Wiederanlauf-Eigenschaft generiert ist (Generierungs-Operanden RESTART=YES der LTERM bzw. USER-Anweisung, siehe openUTM-Handbuch „Anwendungen generieren“). Nach einem Anwendungsende ist in stand-alone UTM-Anwendungen ein Vorgangswiederanlauf nur in UTM-S-Anwendungen möglich.

• Ein PEND SP ist bei verteilter Verarbeitung über LU6.1 nur erlaubt, wenn keine Partner-Vorgänge mit offenen Transaktionen vorhanden sind.

• Wird eine Nachricht an einen HTTP-Client gesendet, so muss der Vorgang mit PEND FI beendet werden, da ein Vorgang für einen HTTP-Client nur einen Dialog-Schritt umfassen darf.

• Ein PEND PA/PR oder SP kann in einem Dialog- oder Asynchron-Vorgang zu einem Prozesswechsel führen, wenn der Folgeteilprogrammlauf in einer anderen TAC-Klasse liegt als der den PEND aufrufende Teilprogrammlauf (siehe openUTM-Handbuch „Anwendungen generieren“, TAC-Klassen), oder wenn die Anwendung mit der Anweisung TAC-PRIORITIES generiert wurde.

• Ein PEND PS-Aufruf darf nur im Anmelde-Vorgang und nur, wenn es der Status des Anmelde-Vorgangs erlaubt, angegeben werden.

• Wird im Anmelde-Vorgang für einen UPIC-Client nach Empfang einer Nachricht vom Client der Aufruf PEND PA/PR oder PS ohne vorhergehenden MPUT-Aufruf ausgeführt, so kann das Folgeteilprogramm nicht gelesene Nachrichten(-teile) vom UPIC-Client noch lesen.

• Ein PEND FC beendet den UTM-Vorgang, aber nicht die UPIC-Conversation.Wird im Anmelde-Vorgang für einen UPIC-Client nach Empfang einer Nachricht vom Client der Aufruf PEND FC ohne vorhergehenden MPUT-Aufruf ausgeführt, so kann das Folgeteilprogramm noch nicht gelesene Nachrichten (-teile) vom UPIC-Client noch lesen. In diesem Fall erhält das erste Teilprogramm des geketteten Vorgangs als Vorgangskennzeichen im KBKOPF den Wert F (First), nicht C (Chained), da es eine Nachricht vom Client erhält.

• Wird ein Asynchron-Vorgang oder ein mit PEND FC geketteter Folge-Vorgang in seiner ersten Transaktion unterbrochen, dann startet openUTM den Vorgang erneut.

• Teilprogrammläufe in Asynchron-Vorgängen dürfen PEND KP und RE nur verwenden, wenn sie zuvor mit einem MPUT eine Nachricht für einen Auftragnehmer-Vorgang bereitgestellt haben.

• Bedenken Sie, dass beim PEND ER/FR im Auftragnehmer-Vorgang keine Nachricht an den Auftraggeber-Vorgang geschickt werden kann (wie beim PEND ER/FR an das Terminal). Trotzdem ist ein MPUT-Aufruf vor dem PEND ER/FR notwendig, sonst beendet openUTM den Vorgang. Der Auftraggeber-Vorgang erhält dann eine Statusinformation mit Vorgangs-Status Z (statt E).

• Bei verteilter Verarbeitung muss beim PEND-Aufruf der Vorgangs- und der Transaktions-Status des Partners beachtet werden. Weitere Informationen hierzu finden Sie im Kapitel „Programmaufbau bei verteilter Verarbeitung".

• Soll auf eine DGET-Nachricht gewartet werden, muss ein PEND PA/PR oder PGWT PR folgen.