IMS Connect
Das IMS Connect-Programmiermodell ermöglicht den Zugriff auf Informationsverwaltungssysteme (Information Management System, IMS) über TCP/IP. In diesem Modell wird die IMS-Nachrichtenwarteschlange zum Verarbeiten von Daten verwendet.
Die folgende Abbildung liefert eine Übersicht über den Workflow zwischen dem Client, dem IMS-Standardlistener, dem Concurrent Server und dem Mainframetransaktionsprogramm. Die Zahlen in Klammern geben die ungefähre Reihenfolge an, in der Ereignisse auftreten. Nach der Abbildung folgt eine ausführliche Beschreibung der Ereignisse.
Prozess, bei dem der Client Eingabedaten an den ITOC-Listener übergibt und HWSIMSO0 Zugriff auf das IMS-Programm bietet, das die Antwortdaten an den Client liefert
Workflowübersichtsdiagramm für das IMS Connect-Programmiermodell
Das IMS Connect-Programmiermodell funktioniert wie folgt:
Eine Anwendung ruft eine Methode in einer TI-Komponente auf, die entweder in Komponentendiensten oder im .NET Framework konfiguriert ist.
TI-Runtime ruft den TI Automation-Proxy auf.
Wenn es sich bei der Anwendung um eine .NET Framework-Assembly handelt, führt der TI Automation-Proxy folgende Schritte aus:
Liest die Assembly und die Metadaten, die zuvor vom TI-Designer erstellt wurden.
Ordnet die .NET-Datentypen COBOL-Datentypen zu.
Der TI Automation-Proxy führt dann folgende Schritte aus:
Ruft die Konvertierungsroutinen auf, um die Anwendungsdaten in Mainframe-COBOL-Typen zu konvertieren.
Erstellt den vereinfachten Datenstrompuffer, der die COBOL-Deklaration oder das COBOL-Copybook darstellt.
Er übergibt die Nachricht an die TCP-Transportkomponente.
TI-Runtime sendet eine erste Anforderungsnachricht (Initial Request Message, IRM) an IMS Connect, entweder HWSIMSO0 oder HWSIMSO1. Dazu werden die Internet Protocol(IP)-Adresse des Mainframecomputers und die Portadresse von IMS Connect verwendet, die im von IBM bereitgestellten TCP/IP-Profildatensatz (hlq. Profil. TCPIP) gespeichert ist.
HWSIMSO0 und HWSIMSO1 sind von IBM bereitgestellte Hostwebserver(HWS)-Exitroutinen, die die Anforderungs- und Antwortprotokolle zwischen dem TI Automation-Server (einer TI-.NET Framework-Anwendung) und ITOC definieren. Der HWS wird in einem z/OS-Adressraum ausgeführt, der von den IMS-Regionen getrennt ist, und führt die Listenerdienste für die IMS-Verbindung aus.
Die IMS Connect-Exitroutine übernimmt die Kontrolle über die IMS-Anwendung (als „IMS TCP/IP Open Transaction Management Architecture (OTMA) Connection“ (ITOC) bezeichnet).
Die TI-Runtime-Umgebung sendet einen ITOC-Anforderungsheader an ITOC und HWSIMSO0.
Die HWSIMSO0-Exitroutine:
überprüft den ITOC-Anforderungsheader
empfängt alle Anforderungsdaten aus der TI-Runtime-Umgebung
kommuniziert mit Sicherheitsroutinen
steuert den OTMA-Prozess zum Herstellen einer Verbindung mit einem IMS-Datenspeicher
platziert Nachrichtensegmente über OTMA in der IMS-Nachrichtenwarteschlange bzw. ruft sie daraus ab
sendet alle Antwortdatensegmente an die TI-Runtime-Umgebung
steuert Wiederherstellungsvorgänge in IMS
ITOC liest die ITOC-Headerinformationen, sucht die richtige IMS-Region und plant die Ausführung einer IMS-Transaktion in dieser IMS-Region. Der ITOC-Header muss die folgenden Informationen enthalten:
ITOC HWS-Exitroutinebezeichner (Standard "*IRMREQ*")
IMS-Datenspeicherbezeichner
Transaktionsbezeichner
Flusssteuerungsinformationen
IBM RACF-Sicherheitsanmeldeinformationen (RACF = Resource Access Control Facility)
Protokollsteuerungskennzeichen
HWSIMSO0 plant die korrekte IMS-Nachrichtenwarteschlange
TI-Runtime sendet die Anforderungsdatensegmente an ITOC
TI-Runtime sendet EOM
IMS-Steuerungsregion sendet an Nachrichtenverarbeitungsregion (MPR)
Nachdem alle Anforderungsdaten in der IMS-Nachrichtenwarteschlange platziert wurden, wird die Ausführung der Transaktion geplant
Das IMS-Serveranwendungsprogramm verwendet die Call Interface-Standardbefehle CBLTDLI Get Unique (GU), Get Next (GN) und Insert (INSRT), um die Anforderungsdaten abzurufen und Antwortdaten in der IMS-Nachrichtenwarteschlange zu platzieren.
MPR gibt Daten an TI zurück. ITOC sendet EOM-CSMOKY und gibt die folgenden Informationen an die TI-Runtime-Umgebung zurück:
RMM (Request Mod Message)
Antwortdatensegmente
Nachrichtenendesegment
CSMOKY-Segment
ITOC und die ITOC-Exitroutine entfernen dann die Antwortdaten aus der Nachrichtenwarteschlange und senden sie an die TI-Runtime-Umgebung zurück.
Der TI Automation-Proxy empfängt die Antwortdaten und verarbeitet die Antwort. Der TI Automation-Proxy führt folgende Schritte aus:
Er empfängt die Nachricht von der TCP-Transportkomponente.
Er liest den Nachrichtenpuffer.
Wenn es sich bei der Anwendung um eine .NET Framework-Assembly handelt, führt der TI Automation-Proxy folgende Schritte aus:
Er ordnet die COBOL-Datentypen .NET Framework-Datentypen zu.
Er ruft die Konvertierungsroutinen auf, um die Anwendungsdaten in OS/400-RPG-Typen zu konvertieren.
TI-Runtime sendet die konvertierten Daten zurück an die .NET Framework-Anwendung, die die Methode aufgerufen hat.
Informationen zum Konfigurieren des Mainframes und zum Schreiben von Serveranwendungen für TCP/IP finden Sie unter TCP/IP V3R2 für z/OS: IMS TCP/IP Application Developers Guide (IBM Document #SC31-7186) und IMS Connect Guide and Reference V1R2 (IBM Document #SC27-0946).
Host Integration Server enthält Beispielcode, der zeigt, wie das IMS Connect-Programmiermodell implementiert wird. Der Beispielcode befindet sich hier: \Installationsverzeichnis\SDK\Samples\AppInt. Starten Sie Visual Studio, öffnen Sie das gewünschte Tutorial, und befolgen Sie die Anweisungen in der Readme-Datei.
Weitere Informationen
Komponenten von Transaction Integrator
Konvertieren von Datentypen von Automation zu z/OS COBOL]
Konvertieren von Datentypen von z/OS COBOL in Automation
IMS-Komponenten
TI-Runtime
Auswählen des geeigneten Programmiermodells
Programmiermodelle