Bei der Schnittstelle XATMI kann lediglich die letzte Ausgabenachricht gelesen werden, siehe Abschnitt „Wiederanlauf“. Ein echter Wiederanlauf ist nur mit der CPI-C-Schnittstelle von UPIC möglich, da diese mit Mehrschritt-UTM-Vorgängen kommunizieren kann. Die folgende Beschreibung bezieht sich daher nur auf CPI-C-Client-Programme.
Mit der UTM-Benutzerkennung ist ein Vorgangskontext verbunden. Der Vorgangskontext enthält z.B. die letzte Ausgabenachricht und Vorgangsdaten wie KB und LSSBs usw. Zusätzlich kann der Client auch einen Client-Kontext an die UTM-Anwendung senden, siehe Abschnitt „Wiederanlauf mit Client-Kontext“.
Die Wiederanlauffähigkeit hängt davon ab, wie eine UTM-Benutzerkennung generiert ist:
Ist eine UTM-Benutzerkennung mit USER ...,RESTART=YES (Standardwert) generiert, dann führt openUTM nach Systemausfällen oder nach dem Verlust der Verbindung zum Client einen Vorgangs-Wiederanlauf durch; openUTM reaktiviert für die Benutzerkennung den Vorgangskontext und ggfs. den Client-Kontext.
Ist eine UTM-Benutzerkennung mit RESTART=NO generiert, dann führt openUTM keinen Vorgangs-Wiederanlauf durch. Auch nicht, wenn der vom Client verwendete LTERM-Partner mit LTERM ...,RESTART=YES generiert ist.
Vorgangs-Wiederanlauf heißt: Nach erneutem Anmelden des Clients setzt die Verarbeitung am letzten Sicherungspunkt eines noch offenen Vorgangs wieder auf. openUTM überträgt die letzte Nachricht des noch offenen Vorgangs und ggf. den Client-Kontext erneut an den Client. Dieser kann den Vorgang dann weiterführen.
Existiert unter der Benutzerkennung ein offener Vorgang für den Client, dann muss dieser Vorgang unmittelbar nach dem nächsten Anmelden weitergeführt werden, sonst beendet openUTM den offenen Vorgang abnormal.
Das Client-Programm muss den Wiederanlauf initiieren, indem es zuerst eine neue Conversation aufbaut und dabei beim Aufruf Set_TP_Name() den Transaktionscode KDCDISP übergibt. Das folgende Beispiel skizziert ein solches „Wiederanlauf-Programm“ für CPI-C.
Initialize_Conversation (...) Set_Conversation_Security_Type (...,CM_SECURITY_PROGRAM,..) 1. Set_Conversation_Security_User_ID (...,"UTMUSER1",..) 1. Set_Conversation_Security-Password (...,"SECRET",..) 1. Set_TP_Name (...,"KDCDISP",...) 2. Allocate (...) Send_Data (...) 3. /* Leere Nachricht */ Receive (...) return_code=CM_OK /* Vorgang offen, Senderecht geht an Client */ /* Kommunikation mit UTM-Vorgang fortsetzen */ status_received=CM_SEND_RECEIVED 4. /* oder */ return_code=CM_DEALLOCATED_NORMAL 5. /* Vorgangsende, Wiederanlauf beendet */ /* oder */ return_code=CM_TP_NOT_AVAILABLE_NO_RETRY 6. /* Wiederanlauf nicht möglich */
Das Programm benutzt die Zugangsschutz-Funktionen von openUTM und setzt explizit die UTM-Benutzerkennung und das Passwort.
Das Programm muss für den Wiederanlauf TP_name auf KDCDISP setzen.
Bei Send_Data dürfen keine Daten gesendet werden, d.h. send_length muss auf 0 gesetzt sein („Leere Nachricht“).
Die Verarbeitung und die Kommunikation mit dem UTM-Vorgang können fortgesetzt werden.
Das Programm hat bereits die letzte Ausgabenachricht erhalten, auf UTM-Seite ist kein Vorgang mehr offen.
Wegen UTM-Neugenerierung ist kein Wiederanlauf möglich.
Als Ergebnis eines solchen Wiederanlauf-Programms erhält der Client beim Receive immer die letzte Ausgabenachricht von openUTM.
Ein Benutzer kann sich unter einer bestimmten Benutzerkennung auf verschiedene Arten an einer UTM-Anwendung anmelden:
von einem Terminal aus
über einen Transportsystem-Anwendung
über Client-Programme mit verschiedenen Trägersystemen
Ein Wiederanlauf durch ein Client-Programm ist nur möglich, wenn die Benutzerkennung zuletzt auch von einem Client-Programm mit demselben Trägersystem verwendet wurde. Ist dies nicht der Fall, dann lehnt openUTM die Anmeldung des Client-Programms ab (CM_SECURITY_NOT_VALID), da der offene Vorgang zunächst von dem Partner beendet werden muss, der ihn gestartet hat.
Ist beim Conversation-Aufbau mit KDCDISP kein offener Vorgang vorhanden, so beendet openUTM die Conversation nach dem Senden der letzten Ausgabenachricht des vorherigen Vorgangs. Wurde der letzte Vorgang von einem anderen Partner gestartet, dann übergibt openUTM keine Nachricht (Returncode CM_TP_NOT_AVAILABLE_NO_RETRY).
Ist nach einer Neugenerierung der UTM-Anwendung kein Anwendungskontext vorhanden, dann erhält das Programm den Returncode CM_TP_NOT_AVAILABLE_NO_RETRY. openUTM beendet die Conversation.
Nach dem Erzeugen einer neuen KDCFILE für die UTM-Anwendung müssen offene Vorgänge eines Clients durch das UTM-Tool KDCUPD übertragen werden.
Wiederanlauf mit Client-Kontext
Der Client kann mit jeder Benutzernachricht einen so genannten „Client-Kontext“ an die UTM-Anwendung schicken. Ein Client-Kontext besteht aus einer maximal 8 Byte langen Zeichenkette. Dies kann z.B. die Uhrzeit oder eine Nachrichten-ID sein.
Falls die Benutzerkennung mit RESTART=YES generiert ist, dann wird der Client-Kontext von openUTM so lange gesichert, bis die Conversation beendet oder bis der Kontext durch einen neuen Kontext überschrieben wurde.
Wenn der Client einen Wiederanlauf anfordert, dann überträgt openUTM den Client-Kontext zusammen mit der letzten Dialog-Nachricht an den Client. Damit kann das Programm anhand des Client-Kontexts eindeutig feststellen, an welcher Stelle im Dialog der Wiederanlauf stattfindet und wie es darauf reagieren muss, z.B. durch Ausgabe eines bestimmten Formulars. Zum Setzen und Lesen des Client-Kontexts gibt es folgende UPIC-Aufrufe:
Set_Client_Context(): Client-Kontext setzen
Extract_Client_Context(): Den letzten von openUTM gesendeten Client-Kontext ausgeben