DE69316639T2

DE69316639T2 - System und verfahren zur schnittstellenbildung fur transaktion-verarbeitungssystem

Info

Publication number: DE69316639T2
Application number: DE69316639T
Authority: DE
Inventors: Reiner D-6830 Schwetzingen Burton; Matthew M. Beaverton Mi 48612 Diment; Peter W. Midland Mi 48642 Gilbert; Brian J. Midland Mi 48640 Walters
Original assignee: Dow Chemical Co
Current assignee: Dow Chemical Co
Priority date: 1992-10-15
Filing date: 1993-10-14
Publication date: 1998-07-16
Anticipated expiration: 2013-10-15
Also published as: CA2146984C; WO1994009430A1; US5530848A; EP0664904A1; DE69316639D1; EP0664904B1; CA2146984A1

Description

1. Gebiet der Erfindung

Die vorliegende Erfindung betrifft allgemein Computerschnittstellen, und insbesondere ein System und ein Verfahren zur Schnittstellenbildung eines Transaktions- Verarbeitungssystems.

2. Zugehöriger Stand der Technik

Gegenwärtige Entwicklungen in der Computertechnologie und in der auf Computer bezogenen Technologie haben in der Verwendung von Computern bei zahlreichen Geschäftsanwendungen resultiert. Nahezu in jedem Bereich der heutigen Industrie werden auf irgendeine Weise Computer und Computersysteme verwendet. Ein Verwenden von Computern ist für Geschäfte notwendig geworden, damit sie in einer wettbewerbsfähigen Stellung bleiben können.
Computersysteme werden zum Automatisieren von Prozessen, zum Verfolgen von großen Informationsmengen und zum Bereitstellen schneller flexibler Kommunikationen verwendet. Ein Anwendungsbereich, der ein weit gestreutes Anwenden von Computern genießt, ist derjenige von Geschäftstransaktionen. Viele Geschäfte von kleinen "Tante Emma"-Läden bis zu professionellen Büros und Partnerschaften bis hin zu großen Firmen, führen ihre Geschäftstransaktionen bis zu einem gewissen Ausmaß durch einen Computer durch. Transaktionen, die durch einen Computer durchgeführt werden, enthalten ein Buchen, ein Annehmen von Aufträgen und eine Inventarkontrolle, etc. Computer werden bei diesen Transaktionen zum Durchführen einer Vielzahl von Funktionen verwendet.
Das folgende Szenario zeigt ein Beispiel einer durch einen Computer durchgeführten Geschäftstransaktion. Das Computersystem nimmt einen Auftrag von einer externen Quelle an. Die externe Quelle kann ein Computer bei einer Einrichtung eines Kunden, ein Computer bei einem regionalen Verkaufsbüro oder eine manuelle Tastatureingabe bei einem System-Terminal sein. Zusammen mit in Auftrag gegebenen Materialien und Mengen ist eine Kundenidentiflkationsnummer enthalten. Das System verwendet diese Nummer zum Schauen auf bestimmte Informationen über den Kunden, wie beispielsweise eine Buchungsadresse, eine Kreditgrenze, eine Lieferadresse, etc. Die Kreditgrenze kann mit einer Außenstandsbilanz für jenen Kunden verglichen werden, wie sie in einer Buchhaltungs-Datenbank aufgezeichnet ist. Wenn der Auftrag dazu führen wird, daß der Kunde seine Kreditgrenze überschreitet, kann die Transaktion verboten oder zur Autorisierung mit einer Kennung versehen werden.
Informationen, die spezifisch für den Auftrag sind, in bezug auf angeforderte Materialien und eine Menge werden mit einer Inventar-Datenbank verglichen, die die Verfügbarkeit der angeforderten Materialien anzeigt. Basierend auf diesen Informationen wird eine Antwort zum Kunden gesendet, welche den Auslieferungszeitpunkt anzeigt.
Das System sendet eine Nachricht zum Warenhaus, die die Besonderheiten des Auftrags im Detail darlegt. Das Warenhaus bereitet den Auftrag vor und sendet ihn mit der Adresse zum Kunden, die im Auftrag spezifiziert ist. In einem automatisierten Warenhaus wird ein Einstellen, eine Auftragsauswahl und eine Vorbereitung auch durch ein System mit einem Computer durchgeführt.
Wenn einmal der Auftrag vorbereitet und versendet ist, updated das Computersystem eine Datenbank zum Empfangen von Abrechnungen und ein Aufruf wird bei der Buchungsadresse zum Kunden gesendet. Wenn der Kunde die Zahlung anbietet, wird die Datenbank zum Aufnehmen von Abrechnungen einem Updaten unterzogen.
Es gibt viele integrierte Softwareanwendungspakete, die zum Durchführen eines weiten Bereichs von Geschäftsfunktionen verfügbar sind, die jene enthalten, die oben diskutiert sind. Diese Pakete werden in diesem Dokument allgemein Transaktionsverarbeitungs-Softwarepakete genannt. Ein derartiges Paket ist das SAP R12-System, das von SAP America, Inc., 625 North Governor Printz Blvd., Essington, PA 19029 angeboten wird.
Das SAP R/2-System ist ein Transaktionsverarbeitungssystem, das zum Laufen in einem IBM CICs (Kundenschnittstellen-Steuersystem) oder IMS-Umgebung entwickelt ist. SAP verwendet dort, wo es nötig ist, Dienste des Hostcomputers. Beispielsweise kann SAP CICs zur Schnittstellenbildung mit Terminals, Druckern, Datenbanken oder externen Kommunikationseinrichtungen, wie beispielsweise dem virtuellen Telekommunikationszugriffsverfahren (VTAM) von IBM verwenden. SAP ist ein modularisiertes, über ein Tablett angesteuertes System, das Transaktionen zum Durchführen spezifizierter Funktionen verwendet. Diese Funktionen können eine Auftragsverarbeitung, eine Inventarkontrolle und eine Gültigkeitserklärung für einen Aufruf enthalten; eine Finanzbuchhaltung, -planung und -steuerung; eine Produktionsplanung und -steuerung; und eine Produktberechnungsplanung und -steuerung. Die Module sind zueinander vollständig integriert, was integrierte Operationen zuläßt.
Interne Funktionen von SAP werden unter Verwendung seiner eigenen Programmiersprache auf hoher Ebene, nämlich ABAP/4, durchgeführt. ABAP/4 ist auch dafür verfügbar, Anwendern zu erlauben, spezialisierte Anwenderfunktionen und -berichte zu erzeugen. ABAP/4 ist eine Programmiersprache der vierten Generation mit einem sehr dicht integrierten Daten-Dateiverzeichnis.
SAP arbeitet in zwei Betriebsarten, nämlich Online bzw. auf direkte Weise und mittels Stapelverarbeitung. Schnittstellentools bzw. -programmierwerkzeuge sind im SAP dafür verfügbar, zuzulassen, daß andere Anwendersoftware, wie beispielsweise externe Prozesse oder Anwendungen, mit dem SAP-System unter Verwendung der Online- und/oder der Stapelverarbeitungs-Betriebsarten eine Schnittstelle bilden. Beispielsweise kann für ein Kaufanwendungs-Softwarepaket bei einer regionalen Herstellungsfirma eine Schnittstelle mit dem SAP bei einem zur Gesellschaft gehörenden Hauptstellenbüro bilden, um eine automatisierte Eintragung von Empfängen von Rohmaterial zuzulassen.
Das SAP-System stellt eine Anzahl eindeutiger Schnittstellen- Programmierwerkzeuge zur Verfügung, die eine externe Anwendung zum Kommunizieren mit dem SAP-System verwenden kann. Die externen Anwendungen verwenden diese Programmierwerkzeuge zum Senden von Nachrichten zum SAP- System für eine nachfolgende Handlung. In diesem Patentdokument wird der Ausdruck "Nachricht" zur Bezugnahme auf Datensignale verwendet, die zwischen externen Anwendungen und dem Transaktionsverarbeitungssystem übertragen werden. Jede Nachricht kann Daten enthalten, die zum Transaktionsverarbeitungssystem zu senden sind, und Befehle, die dem Transaktionsverarbeitungssystem mitteilen, wie es jene Daten zu behandeln hat.
Jedoch haben herkömmliche durch das SAP vorgesehene Schnittstellen- Programmierwerkzeuge mehrere größere Nachteile. Beispielsweise gibt es im Online-Betrieb, wenn eine Nachricht (beispielsweise ein Auftrag) von einer externen Anwendung zum SAP übertragen wird, keine Bestätigung. In dem Fall eines Auftrags treten die Auftragsdaten in eine Durchgangs-Datenwarteschlange von CICs ein und können nicht verfolgt oder gemanagt werden. In dieser Umgebung kann die externe Anwendung den Status ihres Auftrags nicht bestimmen, oder auch nicht, ob der Auftrag vom SAP empfangen wurde.
Ein weiterer Nachteil von herkömmlichen SAP- Schnittstellenprogrammierwerkzeugen besteht darin, daß Teile des SAP- Onlinesystems abgeschlossen werden, um Stapelverarbeitungs- Schreiboperationen durchzuführen. Folglich können die Online-Transaktionen nicht während einer Stapelverarbeitungs-Eingabesession verwendet werden. Herkömmliche SAP-Schnittstellen haben in bezug auf diesen Nachteil derart gearbeitet, daß zwei Stapelverarbeitungs-Eingabedateien vorgesehen wurden. Eine Stapelverarbeitungs-Eingabedatei dient für Online-Eingaben, während die andere für Stapelverarbeitungseingaben dient. Diese Lösung eines Unterhaltens zweier Datenbanken resultiert in einer erhöhten Flexibilität, aber Stapelverarbeitungsschnittstellen können nur in die Datenbänke eingegeben werden, wenn das Online-System gerade verwendet wird.
Weiterhin benötigen herkömmliche SAP-Schnittstellenprogrammierwerkzeuge Bildschirmpuffer, die die Terminal-Bildschirmansichten anpassen. Dies macht erforderlich, daß eine Bildschirmansichtsdefinition vom SAP zur externen Anwendung exportiert wird. Bei dieser Art von Schnittstelle müssen dann, wenn das SAP-System eingegebene Bildschirmanforderungen ändert, alle externen Prozesse die Art ändem, auf die sie Bildschirme erzeugen.
Diese Probleme in bezug auf eine Schnittstellenbildung sind nicht auf Schnittstellen beim SAP-System beschränkt, sondern gelten auch für Schnittstellen zu Transaktionsverarbeitungssystemen im allgemeinen und für Schnittstellen zwischen Geschäftssoftwareanwendungen. Was benötigt wird, ist ein System und ein Verfahren zur Schnittstellenbildung mit einem Transaktionsverarbeitungssystem, das die Nachteile der durch das SAP bereitgestellten Schnittstellenprogrammierwerkzeuge überwindet. Insbesondere ist das, was benötigt wird, eine Schnittstelle zum SAP- System, die eine Bestätigung zu externen Anwendungen auf einen Empfang einer Nachricht hin bereitstellt, und eine Verfolgung und ein Management der Nachricht zur Verfügung stellt, wenn sie durch das Transaktionsverarbeitungssystem verarbeitet wird.
Ein Bestätigen eines Empfangs einer Nachricht von einer externen Anwendung würde zulassen, daß die externe Anwendung den Zustand der Nachricht immer kennt, der zum Transaktionsverarbeitungssystem gesendet wird. Auf diese Weise würde die externe Anwendung wissen, wann ihre Nachricht durch das Transaktionsverarbeitungssystem empfangen wird, wo jene Nachricht im Transaktionsverarbeitungsprozeß ist, und ob jene Nachricht aufgrund eines Daten- oder Auszeiffehlers nochmals übertragen werden muß.
Was weiterhin benötigt wird, ist eine Transaktionsverarbeitungsschnittstelle, die zuläßt, daß externe Anwendungen Stapelverarbeitungs-Eingabedateien im Online- Betrieb zum Transaktionsverarbeitungssystem senden.
Die beanspruchte vorliegende Erfindung schafft ein System und ein Verfahren zur Schnittstellenbildung eines externen Prozesses oder externer Prozesse zu einem Transaktionsverarbeitungs-System. Die Erfindung sorgt für eine garantierte Ausgabe und Verarbeitung von Nachrichten, die von externen Anwendungen empfangen werden, und sorgt für eine Bestätigung zu einer externen Anwendung, wenn eine Nachricht empfangen wird. Zusätzlich sorgt das Schnittstellensystem für ein Verfolgen und eine Statusüberwachung von Nachrichten während ihrer Verarbeitung. Eine Bestätigung wird zur externen Anwendung geliefert, wenn die Verarbeitung beendet ist.
Das Schnittstellensystem gemäß einem bevorzugten Ausführungsbeispiel weist sieben Untersysteme auf, die jeweils einen bestimmten Prozeß durchführen. Die Prozesse weisen eine Gruppe von Softwarebefehlen auf, die Modul genannt werden. Einige Prozesse weisen mehrere Module auf. Gemäß der vorliegenden Erfindung wird eine Nachricht bei einem Eingangsmodul von einer externen Anwendung empfangen. Drei Typen von Eingangs-Empfangsmodulen sind vorgesehen, um den Eingabeprozeß durchzuführen. Diese Module sind dazu entwickelt, (1) Online- Eingaben von einer externen Computerumgebung, wie beispielsweise einem VAX- Computer von Digital Equipment Corp., (2) Online-Eingaben von einer externen CICs-Bereichsumgebung und (3) Stapelverarbeitungseingaben zu behandeln. Wenn einmal eine Nachricht durch ein Eingabeempfangsmodul empfangen wird, wird die Nachricht in einer Logdatei als Steuerdatensatz für jene Nachricht protokolliert bzw. registriert.
Das Schnittstellensystem weist auch drei Daten-Dateien auf. Eine ist eine Schnittstellensystem-Logdatei, die zum Speichern von sowohl Daten-Datensätzen für Nachrichten mit großen Mengen an Daten als auch von Steuerdatensätzen für alle Nachrichten verwendet wird. Die Schnittstellensystem-Logdatei ist eine physikalische Datei, wird aber als zwei separate logische Datenbanken behandelt. Diese Behandlung ermöglicht eine Aufteilung in separate physikalische Dateien, sollten Notwendigkeiten in bezug auf die Durchführung eine derartige Aufteilung erforderlich machen. Es gibt auch eine Logdatei für nach außen gehende Kommunikationen und eine "Anpassungs"-Datei. Die Anpassungsdatei wird zum Anpassen von Datensätzen im Transaktionsprotokoll des Transaktionsverarbeitungssystems an Datensätze in der Schnittstellen-Logdatei verwendet, um die Ausgabe einer Nachrichtenverarbeitung im Transaktionsverarbeitungssystem zu bestimmen.
Ein Schlüsselmerkmal der Erfindung besteht darin, daß eine Bestätigungsnachricht zurück zu einer externen Anwendung geliefert wird, wenn eine eingegebene Nachricht von jener externen Anwendung empfangen wird. Die Bestätigungsnachricht zeigt an, daß die Nachricht empfangen wurde. Somit weiß die externe Anwendung, daß ihre eingegebene Nachricht durch das Transaktionsverarbeitungssystem empfangen wurde, oder dann, wenn keine Bestätigung empfangen wird, daß die eingegebene Nachricht erneut übertragen werden muß. Als Ergebnis wird die Effizienz und Integrität von Systemoperationen verbessert, weil eine externe Anwendung schnell darüber informiert wird, ob sie eine eingegebene Nachricht erneut übertragen muß.
Ein Trigger-Untersystem ist zum Laufenlassen eines Triggerprozesses vorgesehen. Der Triggerprozeß zeigt dem Transaktionsverarbeitungssystem an, daß eine eingegebene Nachricht empfangen worden ist. Auf eine Initiierung hin untersucht der Triggerprozeß die Logdatei, um zu bestimmen, wenn eine eingegebene Nachricht für eine Ausgabe zum Transaktionsverarbeitungssystem verfügbar ist. Wenn eine eingegebene Nachricht verfügbar ist, sendet der Triggerprozeß die eingegebene Nachricht zum Transaktionsverarbeitungssystem, das einen derartigen Empfang anzeigt. Diese Nachricht wird Triggernachricht genannt. Die Triggernachricht zeigt an, wo das Transaktionsverarbeitungssystem den Steuerdatensatz in der Logdatei finden kann.
Die Triggernachricht zeigt dem Transaktionsverarbeitungssystem an, daß eine Nachricht durch das Schnittstellensystem empfangen worden ist und dazu bereit ist, verarbeitet zu werden. Das Transaktionsverarbeitungssystem kann dann mit einer Verarbeitung der Nachricht beginnen.
Ein Status-Untersystem bietet einen Statusprozeß, der Status-Datensätze einem Updaten unterzieht, die den Status einer eingegebenen Nachricht anzeigen, wenn sie durch das Transaktionsverarbeitungssystem verarbeitet wird. Das Status- Untersystem fügt auch neue Steuerdatensätze zur Logdatei hinzu. Diese Steuerdatensätze werden in der Logdatei gespeichert.
Ein Bestätigungs-Untersystem führt einen Bestätigungsprozeß durch, wobei der Status einer Verarbeitung einer eingegebenen Nachricht zur externen Anwendung zurückgesendet wird. Der Bestätigungsprozeß untersucht die Logdatei, um den Status der Transaktionsverarbeitung von empfangenen eingegebenen Nachrichten zu bestimmen. Für jede eingegebene Nachricht, die verarbeitet wird, erzeugt der Bestätigungsprozeß eine Bestätigungsnachricht und speichert sie in einer Datei für eine nach außen gehende Kommunikation für eine nachfolgende Übertragung zu einer externen Anwendung.
Ein Kommunikations-Untersystem ist vorgesehen, um nach außen gehende Nachrichten vom Schnittstellensystem zu jeder ursprünglichen externen Anwendung zu senden, oder zu einer Stelle, die als Zielort definiert ist, um derartige Bestätigungen für eine externe Anwendung zu empfangen. Mehrere Prozesse für eine nach außen gehende Kommunikation können gleichzeitig existieren. Ein Kommunikationsüberwachungs-Untersystem ist vorgesehen, um die Prozesse für eine nach außen gehende Kommunikation laufen zu lassen, zu steuern und zu managen. Das Schnittstellensystem gemäß der vorliegenden Erfindung behandelt drei Klassen von Nachrichten. Diese enthalten reguläre Nachrichten, Kettennachrichten und eine große Menge an Nachrichten. Reguläre Nachrichten weisen unabhängige Nachrichten auf, die für sich selbst vollständig sind und unabhängig von einer beliebigen anderen Nachricht ausgegeben werden. Für jede reguläre Nachricht wird ein Steuerdatensatz an der Logdatei erzeugt, und ein Trigger wird zum Transaktionsverarbeitungssystem gesendet.
Kettennachrichten stellen eine Gruppe einzelner Nachrichten dar, die in einer vorbestimmten Ablauffolge einzeln zu verarbeiten sind. In jeder anderen Hinsicht sind Ketten nach richten dieselben wie reguläre Nachrichten. Ketten nach richten können entweder endliche Ketten oder unendliche Ketten sein. Unendliche Ketten haben keine Anfangs- oder Endnachricht und können über der Zeit auftreten. Andererseits haben endliche Ketten eine unterschiedliche erste und letzte Nachricht. Große Nachrichten weisen eine Gruppe von Nachrichten auf, die als Gesamtheit oder als Stapel verarbeitet werden. Für jede Gruppe eines Stapels von Nachrichten existiert ein Steuerdatensatz, der die Stelle und die Anzahl von Daten-Datensätzen anzeigt, die beteiligt sind. Beim Managen des Fließens von Nachrichten durch das Schnittstellensystem verarbeiten die Untersysteme nur den Steuerdatensatz. Wenn einmal die großen Datennachrichten empfangen werden, verarbeitet das Transaktionsverarbeitungssystem die Daten-Datensätze. Für die Gruppe wird nur eine Bestätigung gesendet. Für nach außen gehende große Gruppen verarbeitet das Modul für eine nach außen gehende Kommunikation nur die Daten-Datensätze. Ein Überwachungs-Untersystem ist vorgesehen, um Zeitabtastungen oder Ereignisse zu erzeugen, die zum Initiieren bestimmter Schnittstellensystemprozesse nötig sind. Beispielsweise werden der Triggerprozeß und der Bestätigungsprozeß durch Abtastungen initiiert, die durch das Überwachungs-Untersystem in regelmäßigen Zeitintervallen erzeugt werden. Das Überwachungs-Untersystem plant auch die Inituerung von nach außen gehenden Prozessen. Nach außen gehende Prozesse enthalten ein Senden von Bestätigungen und anderen nach außen gehenden Nachrichten zu den externen Prozessen.
Zusätzlich erkennt die vorliegende Erfindung einen externen Schnittstellenzeitge ber. Der Schnittstellenzeitgeber kann mehrere Prozesse verschiedener Anwendungen starten. Der Schnittstellenzeitgeber stellt eine Kapazität für eine verstrichene Zeit zur Verfügung.
Ein Überwachungs-Programmierwerkzeug ist optional vorgesehen, um zuzulassen, daß zusammenfassende und detaillierte Informationen für jede Nachricht angezeigt werden, wenn sie durch das SAP-System verarbeitet sind. Das Überwachungs- Programmierwerkzeug stellt einen primären Auswahlbildschirm zur Verfügung, wobei Nachrichten oder Gruppen von Nachrichten zur Überwachung ausgewählt werden können. Ein Zusammenfassungslistenbildschirm zeigt die Ergebnisse der Auswahl und zeigt Nachrichteninformationen an, wie beispielsweise einen Nachrichtentyp, eine Stapelverarbeitungsnummer, eine serielle Nummer, einen Prozeßnamen und eine Prozeßzeit. Ein detaillierter Anfangsblockbildschirm ist vorgesehen, um detaillierte Informationen für eine einzelne Nachricht anzuzeigen.
Ein weiterer Vorteil der vorliegenden Erfindung besteht darin, daß sie zuläßt, daß Bediener oder eine externe Anwendung den Status einer eingegebenen Nachricht prüft, während sie durch das Transaktionsverarbeitungssystem verarbeitet wird.
Ein Schlüsselmerkmal der vorliegenden Erfindung besteht darin, daß "flache" Daten-Datensätze zu Geschäftsanwendungen ausgegeben werden, die innerhalb des Transaktionsverarbeitungssystems laufen. Die Geschäftsanwendungen verwenden dann diese Codes zum Aufbauen ihrer eigenen Bildschirmpuffer außerhalb des Schnittstellensystems und innerhalb des Transaktionsverarbeitungssystems, wo die Definitionen der Bildschirme verfügbar sind.
Ein weiterer Vorteil des Schnittstellensystems besteht darin, daß eine einzelne Stelle einer Steuerung zur Schnittstellenbildung zum Transaktionsverarbeitungssystem vorgesehen ist. Alle Schnittstellen sind gemäß dem Schnittstellensystem standardisiert, und die externen Anwendungen müssen nur mit dieser Standard- Schnittstelle kommunizieren. Eine Fehlersuche bei Problemen wird durch diesen Aspekt der Erfindung stark vereinfacht.
Weitere Merkmale und Vorteile des Schnittstellensystems sowie die Struktur und der Betrieb verschiedener Ausführungsbeispiele des Schnittstellensystems werden unten unter Bezugnahme auf die beigefügten Zeichnungen detailliert beschrieben. Die vorliegende Erfindung wird unter Bezugnahme auf die beigefügten Zeichnungen beschrieben. In den Zeichnungen zeigen gleiche Bezugszeichen identische oder funktional ähnliche Elemente. Zusätzlich identifiziert die ganz linke Ziffer eines Bezugszeichens die Zeichnung, in der das Bezugszeichen zuerst erscheint.
Fig. 1 ist ein Blockdiagramm, das das Schnittstellensystem gemäß der vorliegenden Erfindung darstellt.
Fig. 2 ist ein Flußdiagramm, das den allgemeinen Betrieb des Schnittstellensystems gemäß der vorliegenden Erfindung darstellt.
Fig. 3 ist ein Blockdiagramm, das das Schnittstellensystem in einer beispielhaften Umgebung darstellt.
Fig. 4 ist ein Flußdiagramm, das den Betrieb eines Eingabeempfangsprozesses darstellt, der durch ein Eingabeempfangsuntersystem durchgeführt wird.
Fig. 5 ist ein Flußdiagramm, das einen Triggerprozeß darstellt, wie er durch ein Trigger-Untersystem durchgeführt wird.
Fig. 6 ist ein Flußdiagramm, das einen Statusprozeß darstellt, der durch ein Status-Untersystem durchgeführt wird.
Fig. 7A ist ein Flußdiagramm, das einen Bestätigungsprozeß darstellt, wie er durch ein Bestätigungs-Untersystem durchgeführt wird.
Fig. 7B ist ein Flußdiagramm, das die Schritte darstellt, die beim Ausführen des Schrittes 70B der Fig. 7A beteiligt sind.
Fig. 7C ist ein Flußdiagramm, das darstellt, wie der Bestätigungsprozeß eine Wartung bei Ketten-Datensätzen durchführt.
Fig. 8 ist ein Blockdiagramm, das nach außen gehende Kommunikationen des Schnittstellensystems gemäß der vorliegenden Erfindung darstellt.
Fig. 9 ist ein Flußdiagramm, das den Betrieb eines Prozesses für nach außen gehende Kommunikationen darstellt.
Fig. 10 ist ein Flußdiagramm, das das Verfahren darstellt, durch welches das Schnittstellensystem mit einer externen Anwendung kommuniziert.
Fig. 11 ist eine Fortsetzung von Fig. 10.
Fig. 12 stellt einen detaillierten Anfangsblock-Bildschirm für einen spezifischen Steuerdatensatz dar.
Fig. 13 stellt einen Steuerdatensatz-PC-Bildschirm dar.
Fig. 14 ist ein Flußdiagramm, das den Kommunikationsüberwachungsprozeß darstellt.
Fig. 15 ist ein Blockdiagramm, das ein Überwachungs-Untersystem gemäß der vorliegenden Erfindung darstellt.
Fig. 16 ist ein Flußdiagramm, das den Betrieb des Überwachungs- Untersystems darstellt.
Fig. 17 ist ein Flußdiagramm, das einen Prozeß eines CICS-Startens darstellt.
Fig. 18 ist ein Flußdiagramm, das die Schritte darstellt, die bei einem Stapelverarbeitungszyklus beteiligt sind, der zum Warten einer Schnittstellensystem-Logdatei verwendet wird.
Fig. 19 ist ein Flußdiagramm, das das Verfahren eines Neuorganisierungs- ABAP-Programms darstellt, das zum Neuorganisieren der Logdatei verwendet wird.
Fig. 20 ist ein Diagramm, das einen Listenbildschirm gemäß der vorliegenden Erfindung darstellt.
Fig. 21 stellt einen primären Auswahlbildschirm dar.

INHALTSVERZEICHNIS

1. Überblick über die Erfindung
1.1 Definitionen
1.2 Einführung
2. Umgebung der Erfindung
3. Detaillierte Beschreibung des bevorzugten Ausführungsbeispiels
3.1 Klassen eines Nachrichtendienstes
3.2 Funktionen
3.3 Untersysteme für nach innen gehende Funktionen
3.3.1 Eingabeempfangsmodule
3.3.2 Triggerprozeß
3.3.3 Statusprozeß
3.3.4 Bestätigungsprozeß
3.4 Untersystem für nach außen gehende Funktion
3.4.1 Kommunikationsüberwachungs-Untersystem und prozeß
3.4.2 Kommunikations-Untersystem und prozeß
4. Überwachungsprozeß
5. Starten des Schnittstellensystems
6. Abschalten
7. Datei-Neuorganisation
8. Anzeigefunktion
9. Schluß

1. Überblick über die Erfindung

Die vorliegende Erfindung ist auf ein System und ein Verfahren zur Schnittstellenbildung eines externen Prozesses oder einer Anwendung (Anwenderprogramm) zu einem Transaktionsverarbeitungssystem gerichtet. Das Schnittstellensystem der Erfindung sorgt für eine garantierte Ausgabe und Verarbeitung von Nachrichten, die von externen Anwendungen empfangen werden. Zusätzlich liefert das Schnittstellensystem eine Bestätigung zu einer externen Anwendung, wenn eine Nachricht empfangen wird, und eine Bestätigung, wenn die Verarbeitung beendet ist. Das Schnittstellensystem sorgt auch für eine Nachrichtenverfolgung und eine Statusüberwachung.
Bei einem bevorzugten Ausführungsbeispiel schafft die Erfindung eine Schnittstelle zu einem SAP-System, wie es oben beschrieben ist. Alternative Ausführungsbeispiele schaffen eine Schnittstelle zu anderen Geschäftsanwendungen oder Transaktionsverarbeitungssystemen.

1.1 Definitionen

Ein "Prozeß" ist eine Arbeitseinheit, die unabhängig von anderen Arbeitseinheiten durchgeführt werden kann.
Eine "Transaktion" ist ein Prozeß, der durch einen Namen zum Transaktionsverarbeitungssystem definiert ist, der eines oder mehrere Module identifiziert, welche den Prozeß durchführen werden.
Ein "Modul" ist eine Gruppe oder eine Einheit kompilierter Softwarebefehle. Ein Modul kann einen Prozeß in seiner Gesamtheit oder einen Unterprozeß darstellen.
Eine "Aufgabe" ist ein spezifisches Auftreten oder eine spezifische Ausführung eines Prozesses oder einer Transaktion. Mehrere Aufgaben derselben Transaktion können zur selben Zeit existieren.
Eine "Überwachungs"-Aufgabe oder ein prozeß ist eine (einer), deren (dessen) Funktion eher darin besteht, das Fortschreiten anderer Aufgaben zu überblicken oder "zu überwachen", als eine Verarbeitung einer Datennachricht auszuführen.
Ein "Datensatz" ist eine Dateneinheit, die an einem Computersystem gespeichert ist, und zwar für gewöhnlich in einer Datei oder einer Datenbank.
Eine "Nachricht" hat in Abhängigkeit vom Zusammenhang zwei Bedeutungen: als erstes sind Nachrichten die Übertragung eines Daten-Datensatzes zwischen zwei Prozessen. Als zweites sind Nachrichten auch Datenübertragungen zwischen dem Schnittstellensystem und anderen Systemen, wie beispielsweise einem Transaktionsverarbeitungssystem oder externen Anwendungen.
Ein "Ereignis" ist das Auftreten einer Aktivität, wie beispielsweise der Übertragung einer Nachricht. Ereignisse können dazu verwendet werden, die Ausführung einer Aufgabe zu initiieren.
Ein "Steuerdatensatz" ist ein Datensatz an der Schnittstellensystem-Logdatei, der zum Steuern der Verarbeitung einer Nachricht von einer externen Anwendung durch das System verwendet wird. Ein Steuerdatensatz kann die Daten zur Schnittstellenbildung enthalten, oder kann auf eine Gruppe von Daten zur Schnittstellenbildung zeigen.
Ein "aktiver Steuerdatensatz" ist ein Steuerdatensatz, der in einem derartigen Status ist, daß das Schnittstellensystem gegenwärtig an ihm arbeitet, und von dem erwartet wird, daß sich sein Zustand ändert.
Ein "Anfangsblock" ist ein Teil eines Steuerdatensatzes, und zwar für gewöhnlich am Anfang des Datensatzes, der Informationen enthält, die zum Steuern einer Verarbeitung der Nachricht nötig sind.
Ein "Daten-Datensatz" ist einer einer Gruppe zusammengehöriger Datensätze, der nur einen minimalen Anfangsblock enthält, wobei die Gruppe gemeinsam durch einen separaten Steuerdatensatz dargestellt wird.
"Dateityp" ist ein Code mit zwei Buchstaben im Anfangsblock des Datensatzes, der den Typ des Steuerdatensatzes anzeigt, der durch die Daten im Datensatz dargestellt wird. Der Dateityp wird zum Lokalisieren bestimmter Typen von Datensätzen in einem Teil der Datei verwendet. Beispiele von Dateitypen sind in Tabelle 1 gezeigt.
Ein "Untersystem" ist die Hardware, die zum Laufenlassen eines Moduls oder von Modulen implementiert ist, um einen Prozeß durchzuführen. Ein Untersystem kann eine physikalische oder eine logische Untergruppe des Schnittstellensystems sein. Tabelle 1 In der Logdatei 122 benutzte Dateitypen

1.2 Einführung

Fig. 1 ist ein Blockdiagramm, das ein Schnittstellensystem 100 gemäß der vorliegenden Erfindung darstellt.
Gemäß dem bevorzugten Ausführungsbeispiel weist das Schnittstellensystem 100 sieben Untersysteme und drei Daten-Dateien auf. Die sieben Untersysteme enthalten ein Eingabeempfangs-Untersystem 102, das einen Eingabeempfangsprozeß durchführt, ein Trigger-Untersystem 104, ein Status-Untersystem 106, ein Bestätigungs-Untersystem 108, ein Kommunikationsüberwachungs-Untersystem 110, ein Überwachungs-Untersystem 112 und ein Kommunikations-Untersystem 114. Die drei Daten-Dateien des Schnittstellensystems 100 enthalten eine Schnittstellensystem-Logdatei 122, die Logdatei 122 genannt wird, eine Anpassungs-Datei 124 und eine Logdatei 126 zur nach außen gehenden Kommunikation.
Die Logdatei 122 wird zum Speichern von Steuerdatensätzen 148 verwendet. Der Zweck und die Funktion der Steuerdatensätze 148 wird unten beschrieben.
Die Anpassungs-Datei 124 ist im wesentlichen eine lndexverbindungs-Logdatei 122 mit einer Transaktionsverarbeitungssystem-Logdatei 128.
Eine Kommunikations-Logdatei 126 wird zum Bilden einer Warteschlange von nach außen gehenden Nachrichten 140 verwendet. Nach außen gehende Nachrichten 140 werden gemäß ihrem Zielort in eine Warteschlange gebracht. Nach außen gehende Nachrichten 140 werden basierend auf Ausgabe-Steuerdatensätzen 138 erzeugt, die durch das Bestätigungs-Untersystem 108 geschickt werden. Das Eingabeempfangs-Untersystem 102 antwortet auf ein Empfangen von eingegebenen Nachrichten 132 von externen Anwendungen und zum Protokollieren eines Empfangs davon an der Logdatei 122. Das Trigger-Untersystem 104 führt einen Triggerprozeß durch. der Triggerprozeß sieht sich in der Logdatei 122 um und sucht nach empfangenen Nachrichten. Wenn eine empfangene Nachricht gefunden wird, informiert das Trigger-Untersystem 104 ein Transaktionsverarbeitungssystem 180 darüber, daß eine Nachricht vorhanden ist, die eine Aktion benötigt. Das Status-Untersystem 106 empfängt Informationen in der Form von Verarbeitungsstatus-Nach richten 150 vom Transaktionsverarbeitungssystem 180 bezüglich des Status der Nachrichtenverarbeitung. Diese Informationen werden dann zum Updaten der Logdatei 122 verwendet.
Das Bestätigungs-Untersystem 108 führt einen Bestätigungsprozeß durch, der die Logdatei 122 abtastet und Steuerdatensätze 148 basierend auf Informationen in der Anpassungs-Datei 124 updated, die anzeigen, ob eine Verarbeitung einer Nachricht beendet ist. Es "beendet" Datensätze auch, wenn eine Transaktionsverarbeitung beendet ist oder ein Fehler aufgetreten ist, und dann, wenn eine Bestätigung durch das geeignete Options-Flag angezeigt wird, schreibt es einen Ausgabe-Steuerdatensatz 138 zum Kommunikations-Log-File 126.
Das Kommunikationsüberwachungs-Untersystem 110 führt einen Kommunikationsüberwachungsprozeß durch, der die Datensätze in der Kommunikations- Logdatei 126 überwacht. Das Kommunikationsüberwachungs-Untersystem 110 managt ein vielfaches Auftreten des Prozesses zur Kommunikation nach außen, was sicherstellt, daß nur eine Aufgabe für jeden Zielort gestartet wird, und daß die Nachrichten in der richtigen Reihenfolge übertragen werden.
Das Kommunikationsverarbeitungs-Untersystem 114 führt einen Prozeß zur Kommunikation nach außen durch, der nach außen gehende Nachrichten von der Kommunikations-Logdatei 126 hervorholt, eine Verbindung zu einer externen Anwendung aufbaut und diese Nachrichten zur externen Anwendung sendet.
Fig. 2 ist ein Flußdiagramm, das den Betrieb des Schnittstellensystems 100 gemäß der vorliegenden Erfindung darstellt. Unter Bezugnahme auf Fig. 1 und Fig. 2 wird ein Betrieb des Schnittstellensystems 100 allgemein beschrieben.
In einem Schritt 202 empfängt ein Eingabeempfangs-Untersystem 102 eine eingegebene Nachricht 132 von einer externen Anwendung. Wenn die eingegebene Nachricht 132 empfangen wird, protokolliert das Eingabeempfangs-Untersystem 102 die Nachricht 132 an der Logdatei 122. Beim Protokollieren der Nachricht 132 wird ein Steuerdatensatz 148 für jede eingegebene Nachricht 132 erzeugt. Für alle Nachrichtentypen, die anders als groß sind (unten beschrieben), enthält der Steuerdatensatz 148 einen Anfangsblock und die Daten von der eingegebenen Nachricht 132. Für große eingegebene Nachrichten 132 weist der Steuerdatensatz 148 einen Anfangsblock auf, der ein Flag enthält, das die Existenz einer großen Datengruppe in der Logdatei 122 anzeigt. In einem Steuerdatensatz 148 für eine große eingegebene Nachricht 132 wird ein Flag im Anfangsblock gesetzt, das anzeigt, daß der Steuerdatensatz 148 eine große Menge an Daten darstellt.
Das Schnittstellensystem 100 verarbeitet nur die Steuerdatensätze 148. Genauer gesagt wird nur die Anfangsblockinformationen durch das Schnittstellensystem 100 verarbeitet. Das Schnittstellensystem 100 führt alle seiner Funktionen ohne eine Verarbeitung der Daten durch, die in der eingegebenen Nachricht 132 empfangen werden. Diese Daten werden einfach zwischen dem Transaktionsverarbeitungssystem 180 und die externen Anwendungen geführt, und zwar durch die Verwendung der Steuerdatensätze 148. Wie es oben angegeben ist, sind die Daten für eine reguläre Nachricht innerhalb des Steuerdatensatzes 148 enthalten. Für eine große Menge an Nachrichten weist der Steuerdatensatz 148 einen Zeiger zu den Daten auf.
Das Eingabeempfangs-Untersystem 102 liefert auch eine Bestätigung 144 zurück zur externen Anmeldung, was einen Empfang und ein Protokollieren der eingegebenen Nachricht 132 bestätigt.
Das Eingabeempfangs-Untersystem 102 ist derart konfiguriert, daß es eingegebene Nachrichten 132 von externen Anmeldungen empfängt. Die eingegebenen Nachrichten 132 können beispielsweise Kundencodes, Inventur- oder Produktionsplanupdates, Aufrufinformationen, etc. enthalten. Gemäß einem bevorzugten Ausführungsbeispiel wird eine Vielzahl von Eingabeempfangs-Modulen 162 innerhalb des Eingabeempfangs-Untersystems 102 zur Schnittstellenbildung zu mehreren externen Anwendungen unter Verwendung unterschiedlicher Kommunikationstechniken oder -protokollen verwendet. Jedes Modul 162 verarbeitet Nachrichten auf dieselbe Weise. Jedoch verwendet jedes Modul 162 ein anderes Kommunikationsprotokoll zum Kommunizieren mit externen Anwendungen.
Die Logdatei 122 enthält eine Vielzahl von Steuerdatensätzen 148. Jeder Steuerdatensatz 148 enthält den vollständigen Text einer empfangenen eingegebenen Nachricht 132 (für bestimmte Typen von Nachrichten) zusammen mit Anfangsblockinformationen. Datensätze, die in der Logdatei 122 gespeichert sind, werden gemäß einem Dateitypenfeld (den in Tabelle 1 angezeigten Dateitypen) organisiert. Insbesondere werden aktive Steuerdatensätze 148 zusammen in einem Teil der Logdatei 122 getrennt von Steuerdatensätzen 148 gespeichert, die an Ketten sind und noch nicht zur Verarbeitung bereit sind, und getrennt von Steuerdatensätzen 148, die eine Verarbeitung beendet haben (beendete Steuerdatensätze 148). Durch diese Technik wird eine Verarbeitungseffizienz erreicht. Wenn sich Prozesse nur in den aktiven Steuerdatensätzen 148 umsehen, muß eine minimale Menge an Eingabeverarbeitung durchgeführt werden, weil diese Prozesse sich nicht in beendeten Steuerdatensätzen 148 umsehen müssen.
Die aktiven Steuerdatensätze 148 werden von beendeten Steuerdatensätzen 148 und Kettennachrichtensteuerdatensätzen 148 durch die Verwendung der Dateitypen unterschieden, wie es oben in Tabelle 1 dargestellt ist. Die aktiven Steuerdatensätze 148 für eine ankommende Nachricht sind vom Dateientyp PO. Für Kettennachrichten, die noch nicht bereit zur Verarbeitung sind, ist der Dateientyp PQ. Für Steuerdatensätze 148, die erfolgreich oder fehlerhaft (beispielsweise außerhalb der Zeit) beendet sind, ist der Dateientyp jeweils entweder PR oder PX. Diese Dateientypen sind als Beispiel des bevorzugten Ausführungsbeispiels dargestellt. Man kann sich alternative Ausführungsbeispiele denken, wobei andere Schemen zum Unterscheiden der verschiedenen Steuerdatensätze 148 verwendet werden.
In einem Schritt 204 untersucht ein Trigger-Untersystem 104 die Logdatei 122, um zu bestimmen, ob ein aktiver Steuerdatensatz 184 zur Verarbeitung verfügbar ist. Wenn eine eingegebene Nachricht 132 verfügbar ist, und eine Schwelle eines Nachrichtenvolumens nicht überschritten worden ist, sendet das Trigger- Untersystem 104 eine Triggernachricht 134 zum Transaktionsverarbeitungssystem 180, was anzeigt, daß eine eingegebene Nachricht 132 von einer externen Anwendung empfangen worden ist und auf die Logdatei 122 in der Form eines Steuerdatensatzes 148 protokolliert worden ist. Die Triggernachricht 134 enthält Daten in der Form einer Verschlüsselung, die dem Transaktionsverarbeitungssystem 180 mitteilt, wo der Steuerdatensatz 148 in der Logdatei 122 zu finden ist. Wenn das Transaktionsverarbeitungssystem 180 den Steuerdatensatz 148 liest, auf den durch den Schlüssel gezeigt wird, weiß es, wo die Daten, die zu der zugehörigen eingegebenen Nachricht 132 gehören, am Steuerdatensatz 148 ist.
Der Schlüssel enthält Felder, die einen Dateityp, eine Stapelverarbeitungsnummer, eine serielle Nummer und einen Datenformatnamen zum Bezeichnen des Typs der erforderlichen Verarbeitung anzeigen. Für eingegebene Nachrichten 132, die Teil einer Kettenpostkette sind, wird die Stapelverarbeitungsnummer im Schlüssel für jede Triggern ach richt 134, die zu einer jeweiligen eingegebenen Nachricht 132 gehört, dieselbe sein. Wenn große Mengen an eingegebenen Nachrichten 132 empfangen werden, werden sie in die Logdatei 122 als einzelner Steuerdatensatz 148 und als einer oder mehrere Daten-Datensätze 149 in die Logdatei 122 protokolliert. Für eingegebene Nachrichten 132, die Teil einer Gruppe einer großen Menge von Daten sind, ist die Stapelverarbeitungsnummer in jedem Daten-Datensatz 149 dieselbe wie die Stapelverarbeitungsnummer des Steuerdatensatzes 148 für jene Gruppe von großen Mengen an Daten.
In einem Schritt 206 unterzieht das Status-Untersystem 106 die Logdatei 122 einem Updaten basierend auf Informationen, die vom Transaktionsverarbeitungssystem 180 empfangen werden. Das Status-Untersystem 106 empfängt eine Verarbeitungsstatusnachricht 150 vom Transaktionsverarbeitungssystem 180. Die Verarbeitungsstatusnachricht 150 kann eine von drei Nachrichtentypen sein. Als erstes kann sie einen vollständig neuen Steuerdatensatz enthalten, was dazu führt, daß ein neuer Steuerdatensatz 148 in der Logdatei 122 erzeugt wird. Als zweites kann die Verarbeitungsstatusnachricht 150 ein Update zu einem Steuerdatensatz enthalten, was dazu führt, daß das Status-Untersystem 106 einen existierenden Steuerdatensatz 184 derart modifiziert, daß der gegenwärtige Verarbeitungsstatus berücksichtigt ist. Als drittes kann die Verarbeitungsstatusnachricht 150 ein Update zu einem Master-Steuerdatensatz 154 enthalten. Der Master-Steuerdatensatz 154 ist ein Steuerdatensatz in der Logdatei 122, der eine Haushaltsinformationen enthält, die zum Schnittstellensystem 100 gehört. Informationen, die im Master- Steuerdatensatz 154 enthalten sind, enthalten Informationen wie beispielsweise die letzte serielle Nummer, die zugeordnet ist, die letzte Stapelverarbeitungsnummer, die zugeordnet ist, und eine Grenze bezüglich der Anzahl von Nachrichten, die zum Transaktionsverarbeitungssystem 180 geschickt werden können.
In einem Schritt 208 wird eine Bestätigungsverarbeitung durch ein Bestätigungs- Untersystem 108 durchgeführt, wobei der Status des Steuerdatensatzes 148 eingestellt wird. Das Bestätigungs-Untersystem 108 untersucht die Anpassungs-Datei 124, um den Status des Transaktionsverarbeitungssystems 180 in den Verarbeitungseingabenach richten 132 zu bestimmen. Die Transaktionsverarbeitungs- Logdatei 128 des Transaktionsverarbeitungssystems 180 wird nicht indiziert. Daher ist zum Zulassen, daß ein Bestätigungs-Modul 108 einen Steuerdatensatz 148 (entsprechend einer bestimmten eingegebenen Nachricht 132) auf der Transaktionsverarbeitungssystem-Logdatei 128 lokalisiert, ein externer Index zur Transaktionsverarbeitungs-Logdatei 182 vorgesehen. Dieser externe Index wird auf der Anpassungs-Datei 124 gespeichert.
Das Bestätigungs-Untersystem 108 liest einen aktiven Steuerdatensatz 148 auf der Logdatei 122, um zu bestimmen, ob eine Verarbeitung jenes Steuerdatensatzes 148 beendet ist, ein Fehler auftrat, oder eine Auszeit aufgetreten ist und die eingegebene Nachricht 132 nochmals gesendet werden sollte. Wenn die externe Anwendung forderte, daß eine Bestätigungsstatusnachricht gesendet wird, oder ein Steuerdatensatz 148 anzeigt, daß eine nach außen gehende Datennachricht zu senden ist, speichert das Bestätigungs-Untersystem 108 einen nach außen gehenden Steuerdatensatz 138, der eine Kopie des Steuerdatensatzes 148 ist, in der Kommunikations-Logdatei 126. Die externe Anwendung fragt nach einer Bestätigung durch Setzen eines Options-Flags im Anfangsblock der eingegebenen Nachricht 132. Der nach außen gehende Steuerdatensatz 138 kann ein nach außen gehender Status-Datensatz 138A oder ein nach außen gehender Daten-Datensatz 138B sein. Der nach außen gehende Status-Datensatz 138A ist eine Bestätigung eines hereinkommenden Steuerdatensatzes 148. Der nach außen gehende Daten- Datensatz 138B enthält nach außen gehende Daten für reguläre Nachrichten oder einen Zeiger zu Daten auf einer Ausgabe-Logdatei 804 (Fig. 8) für Gruppen großer Mengen von Daten.
In einem Schritt 210 untersucht ein Kommunikationsüberwachungs-Untersystem 110, das durch ein Überwachungs-Untersystem 112 gestartet wird, eine Kommunikations-Logdatei 126. Wenn ein nach außen gehender Steuerdatensatz 138 gefunden wird, wird eine Überprüfung durchgeführt, um zu sehen, ob eine Kommunikationsaufgabe bereits mit dem Zielort verbunden ist, der durch jenen nach außen gehenden Steuerdatensatz 138 bezeichnet ist. Wenn es nicht so ist, und wenn es nicht bereits mehr als eine Schwellenanzahl von Kommunikationsaufgaben gibt, die gestartet sind, wird eine für den spezifischen Zielort gestartet werden.
In einem Schritt 212 sendet ein Kommunikations-Untersystem 114 eine resultierende nach außen gehende Nachricht 140 zu einer Stelle, die als Zielort definiert ist. In Abhängigkeit von der durch die eingegebene Nachricht 132 spezifizierte Handlung kann die nach außen gehende Nachricht 140 zur ursprünglichen Anwendung zurückgebracht werden, die die eingegebene Nachricht 134 sendete, oder die nach außen gehende Nachricht 140 kann zu einem alternativen Empfangszielort gesendet werden, wie beispielsweise zu einem weiteren Prozeß oder einer weiteren Anwendung.
Bei einem bevorzugten Ausführungsbeispiel der Erfindung arbeitet das Schnittstellensystem 100 asynchron. Das bedeutet, daß die Untersysteme 102,104,106, 108,110 und 114 ihre Prozesse temporär unabhängig von den anderen Modulen durchführen. Nur dann, wenn eine Handlung für ein Modul erforderlich ist, wird jene Handlung durchgeführt. Eine Handlung ist erforderlich, wenn ein Ereignis auftritt. Ein Ereignis kann beispielsweise die Ankunft einer eingegebenen Nachricht 132 sein.
Das Überwachungs-Untersystem 112 ist für Prozesse vorgesehen, die durch eine Zeitabtastung gestartet werden müssen. Einige Prozesse haben keine Initiierungsereignisse, wie beispielsweise die Ankunft von eingegebenen Nachrichten 132. Das Überwachungs-Untersystem 112 sorgt für ein künstliches Ereignis durch Erzwingen eines Starts dieser Prozesse, so daß diese Prozesse prüfen können, um zu sehen, ob eine Arbeit durchgeführt werden muß. Alle N Sekunden treibt das Überwachungs-Untersystem 112 das Trigger-Untersystem 104 dazu an, die Logdatei 122 zu untersuchen, treibt das Bestätigungs-Untersystem 108 dazu an, eine Statusprüfung durchzuführen und treibt das Kommunikationsüberwachungs- Untersystem 110 dazu an, zu prüfen, ob es zu sendende Nachrichten gibt. Beim bevorzugten Ausführungsbeispiel ist N auf einen Wert eingestellt, der klein genug ist, um sicherzustellen, daß eine Arbeit in einer zeitlich richtigen Weise beendet wird, aber nicht so klein, daß ein unnötiger zusätzlicher Aufwand durch ein zu häufiges Überprüfen verursacht wird, ob Arbeit durchgeführt werden muß.

2. Umgebung der Erfindung

Fig. 3 ist ein Blockdiagramm, das die bevorzugte Umgebung darstellt, in der die vorliegende Erfindung arbeitet.
Das Schnittstellensystem 100 ist eine gesonderte Einheit, die in einem CICS- Bereich 300 existiert. Das Transaktionsverarbeitungssystem 180 läuft auch im CICS-Bereich 300. In der bevorzugten Umgebung ist das Transaktionsverarbeitungssystem 180 das SAP R12-System. Externe Anwendungen 302, 304, 306, die außerhalb des CICS-Bereichs 300 existieren, kommunizieren mit dem Transaktionsverarbeitungssystem 180 durch das Schnittstellensystem 100. Typischerweise existieren die externen Anwendungen 302, 304 und 306 in einer entfernt angeordneten Maschine, und oft bei einer entfernt angeordneten Einrichtung.
In Fig. 3 sind drei Typen externer Anwendungen dargestellt. Beispielsweise kann man die externe Anwendung 302 auf einem beliebigen Computer laufen lassen, der über ein LU6.2-Protokoll kommunizieren kann, wie beispielsweise einem VAX Modell 6000 Computer von Digital Equipment Corp. oder einem IBM- Hauptrechnercomputer, wie beispielsweise ein IBM-Modell 3090-600 oder einem anderen Hauptrechnercomputer, anderen CICS-Bereichen oder Stapelverarbeitungsjobs, die auf derselben Maschine wie der CICS-Bereich 300 laufen.
Alternative Ausführungsbeispiele der vorliegenden Erfindung können in Erwägung gezogen werden, wobei das Transaktionsverarbeitungssystem 180 in einer Umgebung läuft, die eine andere als die CICS-Umgebung ist. In diesem Fall können Protokolle, die andere als das LU6.2-Protokoll sind, zur Schnittstellenbildung von externen Prozessen mit dem Transaktionsverarbeitungssystem 180 verwendet werden. Somit sind externe Prozesse nicht auf LU6.2-Protokolle beschränkt, und das Schnittstellensystem 100 kann bei diesen alternativen Ausführungsbeispielen zum Kommunizieren in Protokollen fähig sein, die andere als das LU6.2-Protokoll sind.
Wie es oben diskutiert ist, enthält das Eingabeempfangs-Untersystem 102 eines oder mehrere Eingabeempfangs-Module 162. Ein anderes Eingabeempfangs- Modul 162 ist für jeden Typ von Kommunikationsprotokoll erforderlich. Jedes Eingabeempfangs-Modul 162 verwendet ein anderes Kommunikationsformat, das zur Schnittstellenbildung mit einem anderen Typ von externer Anwendung geeignet ist. Somit hat ein bevorzugtes Ausführungsbeispiel der vorliegenden Erfindung drei Eingabeempfangs-Module 162.
Es gibt separate Eingabeempfangs-Module, die im Eingabeempfangs-Untersystem 102 für jedes der unterschiedlichen Kommunikationsprotokolle laufen, die durch die externen Anwendungen verwendet werden, aber ihre Funktionen sind grundsätzlich dieselben. Außer für diese Eingabeempfangs-Module ist die gesamte Verarbeitung innerhalb des Schnittstellensystems für alle Typen von externen Anwendungen dieselbe.

3. Detaillierte Beschreibung des bevorzugten Ausfuhrungsbeispiels

Nimmt man wiederum Bezug auf Fig. 1, wie es oben im Unterabschnitt 1 beschrieben ist, empfängt das Schnittstellensystem 100 Nachrichten 132 von externen Anwendungen, bestätigt den Empfang, handelt nach jeder Nachricht 132 und sendet eine resultierende nach außen gehende Nachricht 140, wo es erforderlich ist.

3.1 Klassen des Nachrichtendienstes

Es gibt drei Klassen von Nachrichtendienst, die durch das Schnittstellensystem 100 zur Verfügung gestellt werden. Diese sind reguläre Nachrichten, Kettennachrichten und große Mengen an Nachrichten. Jede davon wird allgemein beschrieben. Reguläre Nachrichten stellen den grundsätzlichen Dienst des Schnittstellensystems 100 dar. Die anderen Klassen sind Variationen dieser Klasse. Für reguläre Nachrichten ist jede Nachricht eine unabhängige Einheit, die in sich selbst vollständig ist. Reguläre Nachrichten werden unabhängig von irgendeiner anderen Nachricht ausgegebenen. Für jede eingegebene Nachricht 132 wird ein Steuerdatensatz 148 an der Logdatei 122 erzeugt, und eine Trigernachricht 134 wird zum Transaktionsverarbeitungssystem 180 gesendet. Von einem Anwenderprogramm, das innerhalb des Transaktionsverarbeitungssystems 180 läuft (wie beispielsweise von einer Geschäftsanwendung innerhalb des SAP) wird erwartet, daß es diesen einen Steuerdatensatz 148 verarbeitet. Wenn nach einer Bestätigung gefragt ist, wird eine Bestätigungsnachricht durch das Bestätigungs-Untersystem 108 erzeugt und durch das Kommunikations-Untersystem 114 zum externen Prozeß gesendet.
Für jede reguläre eingegebene Nachricht 132 wird nur ein Datensatz an die Logdatei 122 gegeben. Dieser wird Steuerdatensatz 148 genannt. Für jede reguläre eingegebene Nachricht 132 enthält ein Steuerdatensatz 148 ein Anfangsblockfeld und die Daten von der eingegebenen Nachricht 132.
Kettennachrichten stellen eine Gruppe regulärer Nachrichten dar, die gleichzeitig zu verarbeiten sind, und zwar in einer vorbestimmten Ablauffolge. Die Ablauffolge wird durch die externe Anwendung definiert. Kettennachrichten werden genau wie reguläre Nachrichten verarbeitet, außer daß die Nachrichten nur in einer Sequenz verarbeitet werden. Eine Kettennachricht wird nicht zur Verarbeitung geschickt, bis alle vorherigen Nachrichten in der Kette beendet worden sind.
Es gibt zwei Arten von Ketten. Diese sind unendliche Ketten und endliche Ketten. Unendliche Ketten haben keinen Anfang oder kein Ende. Sie existieren während einer Zeit, und eingegebene Nachrichten einer unendlichen Kette können zu einer beliebigen Zeit ankommen. Keine Verbindung ist als erste Verbindung oder als letzte Verbindung identifizierbar.
Endliche Ketten (FML-Ketten) haben andererseits eine unterschiedliche erste und letzte Verbindung. Jede Kette hat ihren eigenen Anfang oder ihre erste Verbindung ("F") und ihr Ende und eine letzte Verbindung ("L"). Zwischen den F- und L- Verbindungen gibt es eine beliebige Anzahl von mittleren ("M"-)Verbindungen. Wenn eine endliche Kette nur eine Verbindung hat, ist sie per Definition eine L- Kette. Eine Verarbeitung einer endlichen Kette beginnt so lange nicht, bis alle Verbindungen empfangen worden sind. Eine Bestätigung einer endlichen Kette tritt nicht auf, bis die letzte Verbindung verarbeitet ist.
Nun wird ein Beispiel der Nützlichkeit von Kettenverbindungen gezeigt. Wenn ein regionales Verkaufsbüro einen neuen Kunden annimmt, müssen bestimmte Informationen in der Form eines "Kundenmasters" in die Hauptbüro-Datenbanken eingegeben werden, bevor ein Auftrag zur Annahme und Verarbeitung plaziert werden kann. Beispielsweise müssen Kunden informationen wie beispielsweise Buchungs- und Versandadressen und eine Kreditgrenze vorhanden sein, bevor ein Auftrag angenommen wird. Wenn das regionale Verkaufsbüro Nachrichten mit diesen Informationen sendet, sollten die Nachrichten in einer bestimmten Reihenfolge gesendet werden, so daß der Auftrag ohne Fehler verarbeitet werden kann. Für einen Kundenmaster, der zur Datenbank hinzuzufügen ist, müssen das Land, der Staat und die Stadt bereits in der Datenbank existieren. Wenn sie nicht existieren, dann müssen sie in einer bestimmten Reihenfolge gesendet werden, und sie müssen in jener Reihenfolge verarbeitet werden. Diese Reihenfolge der Informationen wird in einem Kettennachrichtenformat präsentiert.
Große Mengen an Nachrichten stellen eine Gruppe von Nachrichten dar, die als eine Einheit oder in einem Stapel verarbeitet werden. Für jede Gruppe von Nachrichten existiert ein Steuerdatensatz. Der Steuerdatensatz zeigt an, welche Anwendung im Transaktionsverarbeitungssystem 180 die gesamte Gruppe verarbeiten wird, und die Anzahl von beteiligten Daten-Datensätzen. Ein Trigger 134 wird zum Transaktionsverarbeitungssystem 180 gesendet, und ein Aufruf der Anwendung im Transaktionsverarbeitungssystem 180 wird zum Verarbeiten aller Datensätze in der Gruppe verwendet. Nur eine Bestätigung wird zur externen Anwendung für die gesamte Gruppe gesendet. Diese Bestätigung enthält einfach eine Zahl der richtig verarbeiteten Nachrichten und die Anzahl von fehlerhaften Nachrichten.
Beim Senden großer Mengen an Nachrichten sendet die externe Anwendung eine oder mehrere Gruppen von Daten bei einer Übertragung oder in einer Datei. Jede Gruppe enthält einen Anfangsblock, eine gewisse Anzahl von Daten-Datensätzen und einen Endblock-Datensatz. Der Endblock-Datensatz wird an der Logdatei 122 in den Steuerdatensatz 148 umgewandelt.

3.2 Funktionen

Das Schnittstellensystem 100 gemäß der vorliegenden Erfindung kann hinsichtlich des Durchführens zweier allgemeiner Funktionen beschrieben werden. Diese sind eine nach innen gehende Funktion zum Empfangen und Verarbeiten hereinkommender Nachrichten von externen Anwendungen, und eine nach außen gehende Funktion zum Erzeugen eines Ausgabezustandes und nach außen gehender Datennachrichten und zum Senden von ihnen zu den externen Anwendungen. Diese Funktionen sind unten in Zusammenhang mit der Diskussion der sieben Untersysteme 102,104,106,108,110, 112,114 des Schnittstellensystems 100 und der Prozesse, die sie durchführen, diskutiert.

3.3 Untersysteme für eine nach innen gehende Funktion

Die hereinkommende Funktion wird von mehreren Untersystemen gemeinsam genutzt. Diese enthalten ein Eingabeempfangs-Untersystem 102, ein Trigger- Untersystem 104, ein Status-Untersystem 106, ein Bestätigungs-Untersystem 108 und ein Überwachungs-Untersystem 112. Die hereinkommende Funktion für jede eingegebene Nachricht 132 endet durch ein Schreiben oder ein Updaten eines Schnittstellen-Zustandscodes und durch Ändern des Dateientyps des Steuerdatensatzes 148 an der Logdatei 122, um anzuzeigen, daß der Steuerdatensatz 148 beendet ist.
Der Steuerdatensatz 148 enthält einen Schnittstellensystem-Zustandscode. Der Wert des Schnittstellensystem-Zustandscodes zeigt an, welches Untersystem die Nachricht zuletzt verarbeitete. Somit hat der Schnittstellensystem-Zustandscode einen eindeutigen Wert, der anzeigt, welche Untersysteme ihre Verarbeitung der eingegebenen Nachricht 132 beendet haben. Jedes Untersystem wird nur einen Datensatz verarbeiten, dessen Schnittstellensystem-Zustandscode anzeigt, daß er zuvor durch das zuvor erforderliche Untersystem (die zuvor erforderlichen Untersysteme) verarbeitet worden ist. Unter Verwendung dieses Schnittstellensystem- Zustandscodes zum Anzeigen eines Beendens und einer Bereitschaft zur Verarbeitung durch das nächste Untersystem läßt zu, daß das Schnittstellensystem 100 Nachrichten asynchron verarbeitet.
Bei einem bevorzugten Ausführungsbeispiel ist der Schnittstellensystem Zustandscode unter Verwendung eines numerischen Wertes von 1 bis 9 bezeichnet. Ebenso ist ein Zustand von "C" enthalten, um anzuzeigen, daß der Steuerdatensatz 148 beendet ist.
Nur aktive Steuerdatensätze 148 werden verarbeitet; jene vom Dateientyp PO und dem nach außen gehenden PM (den Dateientypen, die in Tabelle 1 dargestellt sind). Wie es oben angegeben ist, werden nicht aktive oder beendete Steuerdatensätze nicht verarbeitet. Zusätzlich werden Daten-Datensätze nicht verarbeitet, sondern hereinkommende Daten-Datensätze werden empfangen (beispielsweise die eingegebene Nachricht 132), und nach außen gehende Daten-Datensätze werden gesendet (beispielsweise eine ausgegebene Nachricht).
Einige Module wandeln andere Typen eines Steuerdatensatzes 148 in diese Typen um. Beispielsweise ändert eine Kettennachrichtenverarbeitung Nachrichten vom PQ-Typ in Nachrichten vom PO-Typ um.
Ein PQ-Datensatz stellt eine Kettennachricht dar, die noch nicht zur Verarbeitung verfügbar ist, und zwar entweder aufgrund dessen, daß der vorangehende Datensatz eine Verarbeitung nicht beendet hat, oder deswegen, weu der letzte Datensatz noch nicht empfangen worden ist. Wenn sie verfügbar wird, wird sie in einen Datensatz vom PO-Typ umgewandelt. Wenn einmal eine Verarbeitung eines aktiven Steuerdatensatzes 148 beendet ist, wird er in einen "beendeten" Steuerdatensatz 148 (vom Typ PX oder PR) umgewandelt und wird somit vom Pool der aktiven Steuerdatensätze 148 entfernt.
Nun wird, wiederum unter Bezugnahme auf Fig. 1, die Funktion jedes Untersystems 102,104,106,108,112 beschrieben, das eine hereinkommende Funktion durchführt. Der Prozeß des Eingabeempfangs-Untersystems 102 empfängt eine eingegebene Nachricht 132 von der externen Anwendung und protokolliert einen Steuerdatensatz 148 entsprechend jener Nachricht zur Schnittstellensystem- Logdatei 122. Das Eingabeempfangs-Untersystem 102 erzeugt einen einzelnen Steuerdatensatz 148 für jede eingegebene reguläre Nachricht oder Kettennachricht 132 oder Gruppe von großen Mengen eingegebener Nachrichten 132. Das Eingabeempfangs-Untersystem 102 sendet dann eine Bestätigungsnachricht 144 zur externen Anwendung, daß die eingegebene Nachricht 132 empfangen und protokolliert worden ist. Alternativ dazu veranlaßt das Eingabeempfangs-Untersystem 102, daß ein Flag in einem Kommunikationssteuerblock des Kommunikationsprotokolis gesetzt wird, was veranlaßt, daß das Kommunikationsprotokoll ein Bestätigungs-Flag setzt.
Nach der Verarbeitung durch das Eingabeempfangs-Untersystem 102 wird der Schnittstellensystem-Zustandscode für die eingegebene Nachricht im Steuerdatensatz 148 auf "1" gesetzt. Ein Zustand von "1" zeigt an, daß das Eingabeempfangs- Untersystem 102 seine Verarbeitung der eingegebenen Nachricht 132 beendet hat.
Das Eingabeempfangs-Untersystem 102 wird durch ein Ereignis angetrieben. Anders ausgedrückt führt das Eingabeempfangs-Untersystem 102 seine Verarbeitung nur dann durch, wenn es eine eingegebene Nachricht 132 von einer externen Quelle empfängt (d.h. wenn ein Ereignis auftritt).
Der Triggerprozeß des Trigger-Untersystems 104 durchsucht die aktiven Steuerdatensätze 148 in der Logdatei 122 und sendet eine Triggernachricht 134 zum Transaktionsverarbeitungssystem 180 für jeden aktiven Steuerdatensatz 148, der dazu bereit ist, verarbeitet zu werden. Der Triggerprozeß unterzieht dann den Schnittstellensystem-Zustandscode einem Updaten für den aktiven Steuerdatensatz 148 auf "3", was anzeigt, daß das Trigger-Untersystem 104 seinen Prozeß beendet hat.
Die Triggernachrichten 134 werden zu einem Durchgangsdaten-(TD)- Warteschlangenmechanismus im CICS gesendet. Im Transaktionsverarbeitungssystem 180 wird diese Warteschlangeneinrichtung für Online Datenkommunikationen ODC genannt. Wenn das Transaktionsverarbeitungssystem 180 Daten in der ODC-Durchgangsdaten-(TD)-Warteschlange empfängt, führt es die durch die Daten spezifizierte Transaktion automatisch aus.
Der Triggerprozeß überwacht auch die Anzahl ausstehender Trigger. Ein Trigger wird von der Zeit an als ausstehend angesehen, zu der er zur ODC- Durchgangsdatenwarteschlange übertragen wird, bis die zugehörige eingegebene Nachricht 132 durch das Transaktionsverarbeitungssystem 180 verarbeitet ist, die Verarbeitungszustandsnachricht 150 durch das Transaktionsverarbeitungssystem 180 erzeugt ist und zum Zustands-Untersystem 106 durchgelassen ist, und der aktive Steuerdatensatz einem Updaten auf den Status von "4" unterzogen worden ist.
Wenn die Anzahl von Triggernachrichten 134 eine zuvor ausgewählte Triggerschwelle überschreitet, d.h. die ODC-Warteschlange bis zu einem zuvor ausgewählten Pegel voll ist, überträgt der Triggerprozeß 104 keine zusätzlichen Triggernachrichten 134 zum Transaktionsverarbeitungssystem 180. Dies verhindert ein Überlasten der Warteschlange und beeinflußt die Leistungsfähigkeit der anderen ODC-Warteschlangenbenutzer nachteilig.
Der Betrieb des Triggerprozesses im Trigger-Untersystem 104 wird durch das Überwachungs-Untersystem 112 initiiert, wie es oben im Abschnitt 1.2 dieses Dokuments beschrieben ist. Zusätzlich kann der Triggerprozeß durch das Bestätigungs-Untersystem 108 initiiert werden, wenn es eine Kettennachricht beendet und die nächste Verwendung in der Kette in aktiv umwandelt.
Das Status-Untersystem 106 empfängt Verarbeitungsstatusnach richten 150 vom Transaktionsverarbeitungssystem 180 und updated die Logdatei 122. Der Schnittstellensystem-Statuscode des Status-Untersystems 106 ist "4", was anzeigt, daß das Status-Untersystem 106 seine Verarbeitung beendet hat. Das Status- Untersystem 106 wird durch ein Ereignis angetrieben. Das Status-Untersystem 106 führt seinen Prozeß nur dann durch, wenn das Transaktionsverarbeitungssystem 180 eine Statusverarbeitung anfragt, die zu einer eingegebenen Nachricht 132 gehört. Die Verarbeitungsstatusnachricht 150 kann anzeigen, daß eine vorläufige Verarbeitungsphase im Transaktionsverarbeitungssystem 180 erfolgreich beendet ist, und daß erwartet wird, daß eine weitere Verarbeitung durch das Transaktionsverarbeitungssystem 180 erfolgt. Alternativ dazu kann das Status-Updaten anzeigen, daß einem Fehler begegnet wurde und daß keine weitere Verarbeitung auftreten wird oder daß eine Verarbeitung der eingegebenen Nachricht 132 beendet ist und keine weitere Verarbeitung auftreten wird.
Der durch das Bestätigungs-Untersystem 108 durchgeführte Prozeß dient zum Prüfen eines Verarbeitungsstatus von eingegebenen Nachrichten im Transaktionsverarbeitungssystem180, und dann, wenn es geeignet ist, zum "Beenden des aktiven Steuerdatensatzes 148, und zum Initiieren des Sendens eines nach außen gehenden Steuerdatensatzes 138. In dem Fall von Kettennachrichten wandelt das Bestätigungs-Untersystem 108 die nächste Kettennachricht in der Kette in aktiv um. Der nach außen gehende Steuerdatensatz 138 wird zur Kommunikations- Logdatei 126 gesendet. Der Schnittstellensystem-Statuscode wird einem Updaten auf "8" oder "9" unterzogen, wenn der Bestätigungsprozeß beendet wird. Ein Status von "8" zeigt ein erfolgreiches Beenden (d.h. den Dateientyp PR), während ein Status von "9" ein fehlerhaftes Beenden zeigt (d.h. den Dateientyp PX).
Der Bestätigungsprozeß wird durch das Überwachungs-Untersystem 112 oder durch das Status-Untersystem 106 initiiert. Wenn das Status-Untersystem 106 beispielsweise weiß, daß es den Steuerdatensatz 148 von einem Typ PQ zu einem Typ PO updaten wird, kann es eher den Bestätigungsprozeß starten, als darauf warten, daß der Überwachungsprozeß ihn startet.
Wie es oben diskutiert ist, verwendet das Eingabeempfangs-Untersystem 102 mehrere Eingabeempfangs-Module 162 zum Durchführen des Eingabeprozesses. Jedes der Eingabeprozeß-Module, die im Eingabeempfangs-Untersystem 102 arbeitet, wird nun detaillierter beschrieben.

3.3.1 Eingabeempfangs-Module

Bei den bevorzugten Ausführungsbeispielen gibt es tatsächlich drei Eingabeempfangs-Module, die die Eingabeempfangsverarbeitung des Eingabeempfangs- Untersystems 102 durchführen. Alternative Ausführungsbeispiele können eine andere Anzahl von Eingabeempfangs-Modulen enthalten, wie es erforderlich ist, um eine Schnittstelle zu den externen Anwendungen zu bilden.
Die drei Eingabeempfangs-Module 162 sind derart konfiguriert, daß sie ein LU6.1- Protokoll, ein LU6.2-Protokoll und ein LU2-Protokoll für einen Stapel bearbeiten, der eine Eingabe von Stapelverarbeitungsjobs empfängt. Das LU2-Modul existiert durch die Verwendung einer kommerziell erhältlichen Einrichtung, die als SYSB bekannt ist. SYSB ist von H&W Computing of Boise, Idaho, erhältlich.
Fig. 4 ist ein Flußdiagramm, das die Schritte darstellt, die durch ein Eingabeempfangs-Modul beim Durchführen des Eingabeempfangsprozesses unternommen werden. Unter Bezugnahme auf die Fig. 4 und die Fig. 1 wird nun der Eingabeempfangsprozeß beschrieben. In einem Schritt 402 bildet eine externe Anwendung eine Verbindung zum Schnittstellensystem 100. In einem Schritt 404 führt dann, wenn die externe Anmeldung einmal mit dem Schnittstellensystem 100 verbunden ist, das geeignete Eingabeempfangs-Modul eine Initialisierung durch und empfängt dann eine eingegebene Nachricht 132 von der externen Anwendung. In diesem Schritt können mehrere eingegebene Nachrichten 132 empfangen werden.
In einem Schritt 406 erklärt der Eingabeempfangsprozeß dann, wenn eine eingegebene Nachricht 132 empfangen wird, einige der Anfangsblockfelder der eingegebenen Nachricht 132 für gültig und initialisiert andere Anfangsblock-Felder. Beispielsweise wird der Eingabeempfangsprozeß auf den Anfangsblock schauen, um die Länge des Datensatzes zu bestimmen. Zusätzlich wird dann, wenn der Anfangsblock eine Stapelverarbeitungsnummer von "PO00002 enthält, eine Stapelverarbeitungsnummer erzeugt und zugeordnet. Ebenso nimmt der Eingabeempfangsprozeß dann, wenn eine große Nachricht empfangen wird, keinen zweiten Anfangsblock einer weiteren großen Nachricht an, bis eine Endblocknachricht für die erste große Gruppe empfangen worden ist.
In einem Schritt 408 wird die eingegebene Nachricht 132 zu einer Logdatei 122 als Steuerdatensatz 148 protokolliert. Die eingegebene Nachricht 132, die durch das Eingabeempfangs-Untersystem 102 empfangen wird, kann eine Kettennachricht, eine große Nachricht oder eine reguläre Nachricht sein. Der spezifische Prozeß zum Schreiben des Steuerdatensatzes 148 zur Logdatei 122 ist unabhängig vom Typ der empfangenen eingegebenen Nachricht 132.
Wenn die eingegebene Nachricht 132 eine Stapelverarbeitungsnachricht ist, und wenn die Stapelverarbeitungsnummer "PO0000" ist, findet das Eingabeempfangs- Untersystem 102 die letzte automatisch zugeteilte Stapelverarbeitungsnummer im Master-Steuerdatensatz 154 oder an der Schnittstellensystem-Logdatei 122. Die Nummer wird inkrementiert, verwendet und zur Datei zurückgeschrieben.
Der Steuerdatensatz 148 wird an der Logdatei 122 mit einem Schlüssel gespeichert, der einen Dateientyp, eine Stapelverarbeitungsnummer, eine serielle Nummer und einen Formatnamen aufweist. Die Dateientypen sind oben in Tabelle 1 beschrieben. Die Stapelverarbeitungsnummern sind entsprechend der Steuerung der externen Anwendung, aber die Anwendung kann erfordern, daß das Schnittstellensystem 100 eine eindeutige Stapelverarbeitungsnummer zuteilt. Die Stapelverarbeitungsnummer beginnt mit zwei Zeichen, die eindeutig für das Schnittstellensystem 100 sind, so daß das Schnittstellensystem 100 Nachrichten unter allen anderen Nachrichten erkennen kann, die es erzeugt. Das externe Anwendungssystem führt eine derartige Anfrage durch Bestimmen einer Stapelverarbeitungsnummer von "PO0000" durch. Das Schnittstellensystem 100 antwortet durch Ersetzen der vier Nullen durch vier numerische Ziffern, so daß die Stapelverarbeitungsnummer eindeutig ist.
Stapelverarbeitungsnummern können durch die externe Anwendung zum Gruppieren zugehöriger Nachrichten und zum Abtrennen nicht zugeht nger Nachrichten verwendet werden. Für große Nachrichten und Kettennachrichten müssen alle Elemente der großen Gruppe oder Kette dieselbe Stapelverarbeitungsnummer haben und keine anderen Nachrichten können diese Nummer verwenden. Die serielle Nummer wird immer durch das Schnittstellensystem 100 zugeordnet, wird dazu verwendet, zu erzwingen, daß der Schlüssel an der Datei eindeutig ist, und wird zum Definieren der Reihenfolge eines Empfangs von Nachrichten verwendet. Der Formatname ist ein anwendungsspezifizierter Name, der das Format der Datennachricht definiert, und wird dazu verwendet, zu bestimmen, wie das Transaktionsverarbeitungssystem 180 die eingegebene Nachricht 132 verarbeiten sollte. Wenn die eingegebene Nachricht 132 eine Kettennachricht ist und die Kette unendlich ist, wird dann, wenn ein Steuerdatensatz vom Typ "PO" für die Stapelverarbeitung bereits existiert, der Datensatz als Typ "PQ" gespeichert, um ihn in die Kette wartender Nachrichten anzuordnen. Wenn kein Datensatz vom Typ "PO" existiert, wird er als Typ "PO" gespeichert (siehe Tabelle 1).
Wenn die eingegebene Nachricht 132 eine Kettennachricht ist und die Kette endlich (oder "FML") ist, wird der Datensatz anfangs immer als Typ "PQ" gespeichert. Das Eingabeempfangs-Untersystem 102 wird den F-(ersten)-Datensatz nur zum Typ "PO" ändern, wenn der L-(letzte)-Datensatz empfangen worden ist und in der Logdatei 122 existiert.
Wenn eine große Nachrichtengruppe durch das Eingabeempfangs-Untersystem 102 empfangen wird, enthält die Gruppe immer einen ersten Datensatz vom Typ "pH". Wenn die Nachricht 132 eine große Nachricht ist und der Dateientyp pH ist, zeigt dies somit an, daß eine neue Gruppe gestartet ist. Die große Nachrichtengruppe enthält auch einen oder mehrere Daten-Datensätze von entweder dem Typ PD oder PE, und einen letzten oder Endblock-Datensatz vom Typ "PT". Bei einer Ausführung des Eingabeempfangsprozesses kann mehr als eine Gruppe empfangen werden.
Der erste Datensatz (vom Typ pH) enthält einen Rahmen-Anfangsblock. Nachdem er für gültig erklärt ist, wird er in nachfolgenden Daten-Datensätzen verwendet. Wenn eine vorherige Gruppe keinen Endblock-Datensatz aufweist, wird ein Fehler erklärt (dies wird detaillierter unten diskutiert).
Wenn die eingegebene Nachricht 132 eine große Nachricht ist, und der Dateientyp PD ist, was anzeigt, daß sie ein Daten-Datensatz ist, wird ein abgekürzter Anfangsblock, der in der eingegebenen Nachricht 132 enthalten ist, mit einem Anfangsblock von der zuvor empfangenen pH-Nachricht verbunden, und ein Steuerdatensatz 148 mit einem vollständigen Anfangsblock wird als Typ PZ zur Logdatei 122 geschrieben. Wenn die eingegebene Nachricht 132 eine große Nachricht ist und der Dateientyp PE ist, was auch anzeigt, daß sie ein Daten-Datensatz ist, ist der vollständige Anfangsblock in der Nachricht enthalten. Nach einem für gültig Erklären, wird sie als Typ PZ wie sie ist zur Logdatei geschrieben.
Wenn die Nachricht 132 groß ist, und der Dateientyp PT ist, was anzeigt, daß die Gruppe großer Nachrichten vollständig ist, wird die Gesamtheit der in der großen Gruppe empfangenen eingegebenen Nachrichten 132 mit der Gesamtheit im Endblock-Datensatz verglichen. Wenn die Gesamtheiten nicht übereinstimmen, wird ein Fehler erklärt. Wenn die Gesamtheiten übereinstimmen, wird ein Steuerdatensatz vom Typ PO erzeugt.
Wenn die Nachricht 132 eine reguläre Nachricht ist, wird sie einfach zur Logdatei 122 gelagert, nachdem der Anfangsblock für gültig erklärt ist.
In einem Schritt 410 wird eine Bestätigungsnachricht 144 zur externen Anwendung gesendet. Der Typ der gesendeten Bestätigungsnachricht 144 hängt vom Typ der externen Anwendung ab, die die eingegebene Nachricht 132 zum Eingabeempfangs-Untersystem 102 sendete. Die Bestätigungsnachricht 144 wird ausgegeben, wenn die sendende Anwendung nach ihr fragt, und zwar entweder mittels einer Anfrage zur Bestätigung oder durch Anzeigen, daß sie empfangsbereit ist. In dem Fall von eingegebenen Stapelverarbeitungsnachrichten wird keine explizite Bestätigung 144 gesendet. Alternativ dazu wird ein Flag in einem Kommunikationssteuerblock des Kommunikationsprotokolls gesetzt, was veranlaßt, daß das Kommunikationsprotokoll ein Bestätigungs-Flag setzt.
Wenn im Laufe der Eingabeempfangs-Verarbeitung ein Fehler erklärt wird und die Nachrichtenklasse groß oder eine Kette ist, dann wird der Wert eines Flags, das ABBRUCH_FLAG genannt wird, im Datei-Anfangsblock getestet. Wenn ABBRUCH_FLAG WAHR ist, wird die gesamte Gruppe/Kette abgebrochen. Wenn es FALSCH ist, wird eine Verarbeitung der Gruppe/Kette zugelassen. Die Vorgabe für Kettennachrichten, wenn kein ABBRUCH_FLAG spezifiziert ist, ist FALSCH. Die Vorgabe für groß ist WAHR.
In einem Schritt 412 endet der Empfangsprozeß, wenn die externe Anwendung eine Anfrage zum Lösen der Kommunikationsverbindung ausgibt.

3.3.2 Triggerprozeß

Wie es oben angegeben ist, ist das Trigger-Untersystem 104 zum Informieren des Transaktionsverarbeitungssystems 100 über die Verfügbarkeit einer eingegebenen Nachricht 132 zur Verarbeitung verantwortlich. Im Triggerprozeß gibt das Schnittstellensystem 100 nicht tatsächlich eine eingegebene Nachricht 132 aus, sondern sendet eine Triggernachricht 134 zum Transaktionsverarbeitungssystem 180, um eine spezifische Anwendung aufzurufen, die den Datensatz ausliest und dann verarbeitet, der die eingegebene Nachricht 132 darstellt. Die Triggernachricht 134 enthält Daten, die die Stelle des Datensatzes anzeigen, der die eingegebene Nachricht 132 darstellt. Fig. 5 ist ein Flußdiagramm, das die Schritte darstellt, die durch den Triggerprozeß durchgeführt werden. Unter Bezugnahme auf die Fig. 5 und 1 wird nun der Triggerprozeß beschrieben.
In einem Schritt 502 beginnt der Triggerprozeß. Der Triggerprozeß wird durch ein Zeitabtastungsereignis 146 aufgerufen, das durch das Überwachungs-Untersystem 112 erzeugt wird. Wenn das Überwachungs-Untersystem 112 das Zeitabtastungsereignis 146 zum Trigger-Untersystem 104 ausgibt, beginnt der Triggerprozeß. Zusätzlich zum Aufgerufenwerden durch das Überwachungs-Untersystem 1 12 kann der Triggerprozeß auch durch das Bestätigungs-Untersystem 108 aufgerufen werden. Dies tritt beispielsweise dann auf, wenn das Bestätigungs-Untersystem 108 ein neues Kettenelement freigegeben hat. Zusätzlich wird der Triggerprozeß von einer Stapelverarbeitung aufgerufen, um das Senden von ODCs zu blockieren oder freizugeben.
In einem Schritt 504 wird ein Block-Flag geprüft, um zu bestimmen, ob der Triggerprozeß gesperrt ist. Wenn er blockiert ist, dann endet der Triggerprozeß beim Schritt 518. Wenn der Triggerprozeß jedoch nicht blockiert ist, fährt der Triggerprozeß mit einem Schritt 506 fort.
Im Schritt 506 wird dann, wenn der Triggerprozeß durch entweder das Überwachungs-Untersystem 112 oder das Bestätigungs-Untersystem 108 aufgerufen worden ist, der Zähler des ausstehenden ODC auf Null gesetzt.
In einem Schritt 508 untersucht der Triggerprozeß die Logdatei 122 für aktive Steuerdatensätze 148. Ob ein Steuerdatensatz 148 aktiv ist, wird durch Prüfen des Dateientyps des Steuerdatensatzes 148 bestimmt.
Beim Schritt 509 wird der Status geprüft, um zu sehen, ob er gleich "3" ist. Wenn es so ist, dann wird der ODC-Zähler bei einem Schritt 516 inkrementiert. Ein Status von "3" zeigt einen Steuerdatensatz 148 an, für den eine Triggernachricht 134 zur Warteschlange geschrieben worden ist, aber noch nicht verarbeitet ist. Wenn das Transaktionsverarbeitungssystem 180 den Steuerdatensatz 148 verarbeitet hat, wird der Status zu "4" geändert. Wenn der Status "4" oder großer ist (Schritte 509, 510), fährt der Triggerprozeß mit einer Untersuchung beim Schritt 508 fort.
Jedoch dann, wenn beim Schritt 510 herausgefunden wird, daß der Steuerdatensatz 148 einen Status hat, der kleiner als 3 ist, wird in einem Schritt 512 der ODC- Zähler geprüft, um zu sehen, ob er größer als die zuvor definierte Schwelle ist. Die Schwelle wird derart eingestellt, daß sie einen Überlauf in der ODC-Daten- Warteschlange verhindert. Ein derartiger Überlauf kann auftreten, weil es für das Schnittstellensystem 100 möglich ist, Triggernachrichten zu erzeugen, die schneller sind, als das Transaktionsverarbeitungssystem 180 sie verarbeiten kann. Da die ODC-TD-Warteschlange auch durch andere externe Anwendungen verwendet wird, von denen einige einen Benutzer an einem Terminal enthalten können, der auf eine Antwort wartet, ist es nötig, das Schnittstellensystem 100 von einem Überlasten der Warteschlange abzuhalten. Wie es oben beschrieben ist, wird dies durch Bilden einer Triggerschwelle erreicht, und dadurch, daß jene Schwelle nicht überschritten wird. Ein ausstehender ODC-Zähler wird für jede Ausführung des Triggerprozesses initialisiert, und wird jedesmal inkrementiert, wenn eine Triggernachricht 134 gesendet wird, und jedesmal, wenn einem Steuerdatensatz 148 begegnet wird, für den eine Triggernachricht 134 zuvor gesendet worden ist, für den aber keine Verarbeitungsstatusnachricht 150 empfangen worden ist.
Wenn die Zahl diese zuvor definierte Schwelle übersteigt, wird nichts durchgeführt, und der Prozeß springt zurück zum Schritt 508, um mit der Untersuchung weiterzumachen. Wenn die Zahl die zuvor definierte Schwelle nicht überschreitet, wird bei einem Schritt 514 eine Triggernachricht 134 gebildet und zur ODC-TD- Warteschlange geschrieben. Die Triggernachricht 134 teilt dem Transaktionsverarbeitungssystem 180 mit, daß eine Nachricht verarbeitet werden muß. Die Trigger nachricht 134 enthält auch einen Schlüssel zum Identifizieren der Stelle des Steuerdatensatzes 148 in der Logdatei 122. Eine eindeutige Benutzer-ID wird für jede Nachricht im Schritt 514 erzeugt. Die Benutzer-ID ist aus der Stapelverarbeitungsnummer verkettet mit sechs Ziffern der seriellen Nummer niedrigerer Ordnung aufgebaut. Die resultierende Benutzer-ID wird im Anfangsblock des Steuerdatensatzes 148 gespeichert und der zur ODC-TD-Warteschlange gesendeten ODC- Transaktion zugeordnet. Es ist zu beachten, daß die Stapelverarbeitungsnummern mit den Buchstaben PO beginnen, was dazu führen wird, daß die Benutzer-ID mit diesen Buchstaben beginnt, so daß jede Stapelverarbeitungsnummer für das Schnittstellensystem 100 eindeutig sein wird. Dies ist im Bestätigungsprozeß nötig, der unten unter Bezugnahme auf Fig. 7 beschrieben ist.
In einem Schritt 516 wird der ODC-Zähler inkrementiert und der Triggerprozeß springt zum Schritt 508 zurück, wo das Untersuchen der Logdatei 122 fortgeführt wird.
Im Schritt 508 endet dann, wenn keine Steuerdatensätze 148 mehr in der Logdatei 122 existieren, die Triggeraufgabe. Die Triggeraufgabe wird beim Schritt 502 wiederum beginnen, wenn sie durch das Überwachungs-Untersystem 112 oder das Bestätigungs-Untersystem 108 aufgerufen wird.

3.3.3 Statusprozeß

Das Status-Untersystem 106 führt einen Statusprozeß durch. Das Schnittstellensystem 100 ist derart implementiert, daß nur das Schnittstellensystem 100 die Logdatei 122 updaten kann. Daher müssen Statusupdates vom Transaktionsverarbeitungssystem 180 zur Verarbeitung zum Schnittstellensystem 100 zurückgeführt werden. Diese Funktion wird durch das Status-Untersystem 106 durchgeführt. Das Status-Untersystem 106 wird auch dazu verwendet, Steuerdatensätze 148 an der Logdatei 122 hinzuzufügen oder einem Updaten zu unterziehen.
Fig. 6 ist ein Flußdiagramm, das das Verfahren des Statusprozesses darstellt. Unter Bezugnahme auf die Fig. 1 und 6 wird nun der Statusprozeß beschrieben.
In einem Schritt 602 ruft eine Anwendung, die im Transaktionsverarbeitungssystem 180 läuft, dann, wenn sie mit dem Schnittstellensystem 100 kommunizieren möchte, eine vorgesehene Unterroutine auf. Diese Unterroutine übergibt eine Verarbeitungsstatusnachricht 150, die entweder einen neuen Steuerdatensatz 148 enthält, der zur Logdatei 122 hinzuzufügen ist, oder ein Update zu einem existierenden Steuerdatensatz 148. Zusätzlich kann ein Update zu Master-Steuerinformationen des Schnittstellensystems 100 im Master-Steuerdatensatz 154 gesendet werden.
In einem Schritt 604 wird der Statusprozeß durch das Unterprogramm gestartet, und das Status-Untersystem 106 liest die Verarbeitungsstatusnach richt 150 aus dem Transaktionsverarbeitungssystem 180 aus. Dies ist eine absichtliche asynchrone Unterbrechung, so daß das Schnittstellensystem 100 die Online-Aufgaben nicht verzögert. Wenn der Statusprozeß aufgerufen wird, bestimmt der Prozeß zuerst in einem Schritt 605, ob die Verarbeitungsstatusnachricht 150 ein Update zu einem Steuerdatensatz 148, 154 oder einen neuen Steuerdatensatz 148 enthält. Wenn die Verarbeitungsstatusnachricht 150 ein Update zu einem Steuerdatensatz 148,154 enthält, fährt der Statusprozeß bei einem Schritt 606 fort. Im Schritt 606 wird der einem Updaten zu unterziehende relevante Steuerdatensatz 148, 154 gelesen, einem Updaten unterzogen und zurückgeschrieben. Jedoch dann, wenn die Daten ein neuer Steuerdatensatz 148 sind, werden die Anfangsblockdaten für gültig erklärt und der neue Steuerdatensatz 148 wird in einem Schritt 608 zur Logdatei 122 geschrieben.
In einem Schritt 610 gibt der Statusprozeß dann, wenn der Steuerdatensatz 148 anzeigt, daß die Nachricht Teil einer Kette ist (d.h. ein KETTEN_FLAG-Flag ist gesetzt), einen Startbefehl für das Bestätigungs-System 108 beim Schritt 612 aus. Dies läßt zu, daß das Bestätigungs-Untersystem 108 seinen Prozeß beginnt, ohne auf ein Ereignis vom Überwachungs-Untersystem 112 zu warten. Somit kann das Bestätigungs-Untersystem 108 eine Verarbeitung des nächsten Elements in der Kette starten, ohne auf ein Signal vom Überwachungs-Untersystem 112 zu warten.
Wenn im Schritt 610 der Wert des Schnittstellensystem-Statuscodes anzeigt, daß das Transaktionsverarbeitungssystem 180 eine Verarbeitung der Transaktion beendet hat, wird der Statusprozeß beim Schritt 614 beendet.

3.3.4 Bestätigungsprozeß

Der durch das Bestätigungs-Untersystem 108 durchgeführte Bestätigungsprozeß ist ein Prozeß zum Erhalten von Informationen in bezug auf den Status einer Nachricht im Transaktionsverarbeitungssystem 180 und ein Berichten dieses Status zu einer externen Anwendung. Diese Statusinformationen werden durch Lesen von Informationen in der Anpassungs-Datei 124 oder durch Lesen des Steuerdatensatzes 148 in der Logdatei 122 erhalten. Wenn der Status eine Transaktion darstellt, die das Transaktionsverarbeitungssystem 180 beendet hat, "beendet" das Bestätigungs-Untersystem 108 den Steuerdatensatz 148, und berichtet dann, wenn es aufgefordert wird, diesen Status zur externen Anwendung, die die ursprüngliche zugehörige eingegebene Nachricht 132 sendete. Beim Beenden eines Datensatzes wird der Steuerdatensatz 148 zu einem separaten Teil der Logdatei 122 bewegt, und zwar durch Hinzufügen eines neuen Steuerdatensatzes 148 mit einem Dateientyp und einem Schnittstellensystem-Statuscode, was anzeigt, daß er beendet ist, und durch Löschen des alten Steuerdatensatzes 148. Dann bestimmt das Bestätigungs-Untersystem 108, ob die angefragte eingegebene Nachricht 132 eine Bestätigung ist (d.h. ob ein Flag gesetzt war). Wenn es so ist, wird ein nach außen gehender Steuerdatensatz 138 zur Kommunikations-Logdatei 126 gesendet.
Fig. 7A ist ein Flußdiagramm, das den gesamten Bestätigungsprozeß darstellt, und Fig. 7B stellt einen Teil der Fig. 7A detaillierter dar. Unter Bezugnahme auf die Fig. 1, 7A und 7B wird nun der Bestätigungsprozeß beschrieben. In einem Schritt 702 wird das Bestätigungs-Untersystem 108 durch das Überwachungs-Untersystem 112 aufgerufen, oder durch den Statusprozeß 106.
In einem Schritt 704 untersucht das Bestätigungs-Untersystem 108 die Transaktionsverarbeitungssystem-Logdatei 128 mit einem Suchen nach Transaktions- Datensätzen 158. Transaktionen des Transaktionsverarbeitungssystems 180 erzeugen Transaktions-Datensätze 158. Transaktions-Datensätze 158 können in Antwort auf eine Triggernachricht 134 erzeugt werden, die durch das Schnittstellensystem 100 gesendet wird. Eine Triggernachricht 134 kann in vielen Transaktionen im Transaktionsverarbeitungssystem 180 resultieren, die Transaktions- Datensätze 158 erzeugen, oder kann in keinen Transaktionen resultieren, die einen Transaktions-Datensatz 158 erzeugen. Jeder Transaktions-Datensatz 158, der als Ergebnis einer Transaktion erzeugt wird, die durch die Triggernachricht 134 getriggert ist, wird eine Benutzer-ID enthalten, die mit PO beginnt.
Die Transaktionsverarbeitungssystem-Logdatei 128 kann extrem groß sein und ist nicht für eine direkte Verarbeitung organisiert. Eine sequentielle Verarbeitung der Datei in ihrer Gesamtheit bei jeder Ausführung würde zu viel Zeit brauchen. Somit untersucht der Bestätigungsprozeß nur jene Transaktions-Datensätze 158, die seit der letzten Ausführung des Bestätigungsprozesses zur Transaktionsverarbeitungssystem-Logdatei 128 hinzugefügt worden sind. Das Bestätigungs-Untersystem 108 sucht nach einem Transaktions-Datensatz 158, der eine Transaktion des Schnittstellensystems 100 darstellt. Der Transaktions-Datensatz 158 enthält eine Benutzer-ID, die mit zwei Zeichen beginnt, die für das Schnittstellensystem 100 eindeutig sind, wie es im oben diskutierten Schritt 514 zugeteilt ist.
In einem Schritt 706 wird dann, wenn der Transaktions-Datensatz 158 mit einem Benutzernamen beginnend mit den Buchstaben PO gefunden wird, ein Übereinstimmungs-Datensatz 152 zur Übereinstimmungs-Datei 124 hinzugefügt.
Der Übereinstimmungs-Datensatz 152, der im Schritt 706 erzeugt wird, enthält Datenelemente plus die relative Byte-Adresse (RBA) des Transaktions- Datensatzes 158 an der Transaktionsverarbeitungssystem-Logdatei 128. Dieser Prozeß fährt fort, bis das Ende der Datei gefunden wird. Die höchste RBA, die gelesen wird, wird im Master-Steuerdatensatz 154 an der Logdatei 122 gespeichert.
Wenn beim Lesen der Logdatei 122 einem Fehler begegnet wird, wird die Datei mit der höchsten RBA auf Null gesetzt, die Datensätze an der Übereinstimmungs-Datei 124 werden gelöscht und der Prozeß wird neu gestartet. Somit wird die Übereinstimmungs-Datei 124 aus einer Arbeitsdatei neu aufgebaut.
In einem Schritt 708 untersucht das Bestätigungs-Untersystem 108 Steuerdatensätze 148 an der Logdatei 122 und sucht nach Datensätzen mit einem Status, der größer oder gleich 3 ist. Jeder gefundene Steuerdatensatz 148 wird an Übereinstimmungs-Datensätze 152 in der Übereinstimmungs-Datei 124 angepaßt, um zu bestimmen, ob die Transaktion beendet ist oder ob die Zeit für die Transaktion abgelaufen ist. Der Schritt 708 wird unten unter Bezugnahme auf Fig. 7B detaillierter diskutiert.
In einem Schritt 710 führt das Bestätigungs-Untersystem 108 eine Wartung an verketteten Nachrichten durch. Diese Wartung wird detaillierter unter Bezugnahme auf Fig. 7C diskutiert.
Nun wird der oben beschriebene Schritt 708 detaillierter unter Bezugnahme auf Fig. 7B beschrieben.
In einem Schritt 722 werden aktive Steuerdatensätze 148 an der Logdatei 122 untersucht. Der Bestätigungsprozeß besteht in einem Suchen nach Steuerdatensätzen 148, die einen Schnittstellensystem-Statuscode haben, der größer als oder gleich 3 ist.
In einem Schritt 724 sucht der Bestätigungsprozeß dann, wenn einmal ein Steuerdatensatz 148 mit einem Status, der größer als oder gleich 3 ist, gefunden wird, nach einem entsprechenden Datensatz 152 in der Übereinstimmungs-Datei 124. In einem Schritt 725 fährt der Prozeß dann, wenn ein Übereinstimmungs-Datensatz 152 gefunden wird, bei einem Schritt 726 fort. Wenn kein Übereinstimmungs- Datensatz 152 gefunden wird, fährt der Prozeß bei einem Schritt 727 fort.
Im Schritt 727 bestimmt der Bestätigungsprozeß, ob die Zeit für die Transaktion abgelaufen ist. Die Zeit für die Transaktion ist abgelaufen, wenn ein Zeitintervall zwischen der Zeit, zu der ein Steuerdatensatz 148 durch das Status-Untersystem 106 zuletzt einem Updaten unterogen (oder ergänzt) wurde, und der aktuellen Zeit eine bestimmte Auszeitperiode überschreitet. Somit wird eine Bestimmung durch Vergleichen der letzten Update-Zeit des Steuerdatensatzes 148 mit der gegenwärtigen Zeit durchgeführt. Wenn das Zeitintervall eine im Master-Steuerdatensatz 154 gespeicherte Auszeit übersteigt, wird der Status in einem Schritt 728 derart eingestellt, daß er anzeigt, daß eine Auszeit aufgetreten ist, und der Steuerdatensatz 148 wird fehlerhaft beendet.
Wenn in der Übereinstimmungs-Datei 124 kein entsprechender Übereinstimmungs- Datensatz 152 gefunden wird (Schritt 725), die Zeit für die Transaktion nicht abgelaufen ist (Schritt 727), und es zusätzliche zu untersuchende Steuerdatensätze 148 gibt (Schritt 729), fährt der Bestätigungsprozeß beim Schritt 722 fort. Wenn kein Übereinstimmungs-Datensatz 152 gefunden wird (Schritt 725), aber die Zeit für die Transaktion abgelaufen ist (Schritt 727), geht der Bestätigungsprozeß weiter zu einem Schritt 728, der unten beschrieben ist. Wenn kein Übereinstimmungs- Datensatz gefunden wird (Schritt 725), die Zeit für die Transaktion nicht abgelaufen ist (Schritt 727), es aber keine Steuerdatensätze 148 mehr gibt (Schritt 729), wird der Bestätigungsprozeß beendet.
Wenn andererseits ein Übereinstimmungs-Datensatz 152 gefunden wird (Schritt 725), dann wird in einem Schritt 726 der Transaktionsverarbeitungssystem-Status des Übereinstimmungs-Datensatzes 152 in der Übereinstimmungs-Datei 124 gelesen. Wenn dieser Status anhängig ist (nicht beendet ist), wird in einem Schritt 730 die Transaktionsverarbeitungssystem-Logdatei 128 direkt gelesen, und zwar unter Verwendung der gespeicherten RBA, und der Transaktionsverarbeitungssystem- Status wird sowohl in der Logdatei 122 als auch in der Übereinstimmungs-Datei 124 basierend auf dem Transaktionsverarbeitungssystem-Status des Transaktions- Datensatzes 158 einem Updaten unterzogen. Wenn der Transaktionsverarbeitungssystem-Status beendet ist (Schritt 731), oder wenn die Zeit für die Transaktion abgelaufen ist (Schritt 727), wird der Steuerdatensatz 148 im Schritt 728 beendet.
Im Schritt 728 wird der Steuerdatensatz 148 auf eine von zwei Arten beendet. Bei der einen Art wird dann, wenn der Transaktionsverarbeitungssystem-Status ein Fehler ist, der Schnittstellensystem-Statuscode auf 9 gesetzt und der Dateientyp auf PX eingestellt. Wenn der Transaktionsverarbeitungssystem-Status jedoch ein Erfolg ist, wird der Schnittstellensystem-Statuscode auf 8 gesetzt, und der Dateientyp wird auf PR eingestellt. Der aktive Steuerdatensatz 148 wird gelöscht und ein beendeter Steuerdatensatz 148 (vom Typ PX oder PR) wird zur Logdatei 122 hinzugefügt.
In einem Schritt 732 bestimmt der Bestätigungsprozeß, ob die externe Anwendung, die die eingegebene Nachricht 132 entsprechend dem Objekt-Steuerdatensatz 148 sendete, eine Bestätigung angefordert hat. Eine Bestätigung wird angefordert, wenn ein Flag im Anfangsblock des Steuerdatensatzes, das beim bevorzugten Ausführungsbeispiel SENDEN_WELCHER_STATUS genannt wird, durch die externe Anwendung auf größer als Null gesetzt ist. Wenn keine Bestätigung angefordert wurde, wird der Bestätigungsprozeß zum Schritt 722 zurückspringen, wenn die aktiven Steuerdatensätze 148 noch existieren, um untersucht zu werden (Schritt 729), oder wird enden, wenn keine aktiven Steuerdatensätze 148 zurückbleiben (Schritt 729). Wenn jedoch eine Bestätigung durch die externe Anwendung angefordert wurde, fährt der Bestätigungsprozeß bei einem Schritt 734 fort.
In einem Schritt 734 wird eine Kopie des Anfangsblocks des beendeten Steuerdatensatzes 148 zur Kommunikations-Logdatei 126 als abgehender Status-Datensatz 138A geschrieben. Dies führt dazu, daß eine Statusnachricht zur externen Anwendung gesendet wird. Für den Fall einer einfachen Bestätigung enthält der abgehende Status-Datensatz 138A nur die Anfangsblockinformationen des Steuerdatensatzes 148, was somit alles ist, was zum Zielort gesendet wird. Wenn eine aktuelle Datennachricht zu senden ist, (d.h. mehr als nur eine Bestätigung), werden die Dateninhalte des Steuerdatensatzes 148 auch zusammen mit dem Anfangsblock als abgehender Daten-Datensatz 138B geschrieben.
Fig. 7C ist ein Blockdiagramm, das eine Wartung darstellt, die an Kettennachrichten (vom Typ PQ) durchgeführt wird, die an der Logdatei 122 existieren. Unter Bezugnahme auf Fig. 7C wird in einem Schritt 752 die Logdatei 122 untersucht, um Ketten-Datensätze zu finden (d.h. Datensätze vom Typ PQ). Wenn keine Ketten- Datensätze gefunden werden, fährt der Prozeß beim Schritt 712 fort (Fig. 7B).
In einem Schritt 754 bestimmt der Bestätigungsprozeß, ob die Kette eine endliche Kette ist. Wenn sie eine endliche Kette ist, und wenn ein Ketten-Flag einen ersten oder einen mittleren Ketten-Datensatz in der Kette (jeweils F oder M) anzeigt, prüft der Bestätigungsprozeß in einem Schritt 756, um zu bestimmen, ob der Empfangsprozeß noch aktiv ist. Wenn der Empfangsprozeß noch aktiv ist, kann das Gleichgewicht der Kettennachricht noch dabei sein, empfangen zu werden. Somit wird in diesem Fall nichts in bezug auf jenen bestimmten Steuerdatensatz 148 durchgeführt, und der Bestätigungsprozeß nimmt ein Untersuchen der Logdatei 122 für Ketten-Datensätze vom Typ PQ in einem Schritt 752 erneut auf.
Wenn im Schritt 754 bestimmt wurde, daß die Kette nicht endlich ist, fährt die Verarbeitung auch bei einem Schritt 764 fort.
Wenn andererseits der Steuerdatensatz 148 eine endliche Kette anzeigt und der Empfangsprozeß nicht mehr aktiv ist, sucht der Bestätigungsprozeß nach dem letzten Steuerdatensatz 148 der Kette (L) in einem Schritt 758. Wenn der letzte Datensatz für die Kette nicht existiert (Schritt 759), hat der in der Kette empfangene letzte Steuerdatensatz 148 sein Flag von seinem aktuellen Wert von entweder F oder M zu einem Fragezeichen in einem Schritt 760 geändert. Das Schnittstellensystem 100 behandelt diesen Datensatz genauso, als ob er der letzte Datensatz wäre, zeigt aber an, daß dieser Datensatz von der externen Anwendung nicht als letzter Datensatz empfangen wurde.
Wenn im Schritt 759 ein letzter Steuerdatensatz 148 für die Kette existiert, fährt der Bestätigungsprozeß beim Schritt 764 fort.
In einem Schritt 762 wird ein Abbruch-Flag geprüft, um zu bestimmen, ob diese Kette durch das Schnittstellensystem 100 abgebrochen werden sollte, wenn ein Fehler auftritt (d.h. ob ein Abbruch-Flag wahr ist). Wenn das Abbruch-Flag wahr ist, werden alle übrigen Verbindungen der Kette aufgrund eines Fehlers abgebrochen, der früher in der Kette auftritt, genauso als ob ein Fehler in jeder Verbindung in der Kette auftrat. Wenn jedoch das Abbruch-Flag nicht auf wahr gesetzt ist, fährt die Verarbeitung bei einem Schritt 764 fort.
Im Schritt 764 wird die gefundene Stapelverarbeitungsnummer für jeden PQ- Datensatz geprüft, um zu sehen, ob es einen aktiven Steuerdatensatz 148 vom Typ PO mit derselben Stapelverarbeitungsnummer gibt. Wenn ein PO-Datensatz für die Stapelverarbeitung gefunden wird, wird nichts getan, und die Verarbeitung wird beim Schritt 752 wieder aufgenommen. Wenn andererseits kein PO- Steuerdatensatz 148 für die Stapelverarbeitung gefunden wird, wird das Abbruch- Flag im Anfangsblock des PQ-Datensatzes in einem Schritt 766 getestet. Wenn das Abbruch-Flag nicht anzeigt, daß die Datensätze abzubrechen sind, wenn ein Fehler auftritt, fährt der Prozeß bei einem Schritt 768 fort. Wenn jedoch das Abbruch-Flag anzeigt, daß die Datensätze abzubrechen sind, werden jener PQ- Ketten-Datensatz und alle nachfolgenden Datensätze mit derselben Stapelverarbeitungsnummer als Fehler-Datensätze in einem Schritt 770 beendet.
Im Schritt 768 wird der PQ-Datensatz durch Hinzufügen eines aktiven Steuerdatensatzes 148 (vom Typ PO) und darauffolgendes Löschen des PQ-Datensatzes in einen PO-Datensatz umgewandelt.
An dieser Stelle wird der Bestätigungsprozeß ein Untersuchen der Logdatei 122 nach PQ-Ketten-Datensätzen in einem Schritt 752 wieder aufnehmen.

3.4 Untersystem für abgehende Funktion

Die abgehende bzw. nach außen gehende Kommunikationsfunktion wird durch das Kommunikations-Untersystem 114 und das Kommunikationsüberwachungs- Untersystem 110 durchgeführt. Abgehende Kommunikationen sind in Abhängigkeit davon in unterschiedliche Klassen aufgeteilt, ob der Zielort der abgehenden Kommunikationen ein stapelverarbeitungsorientiertes oder ein Online-System ist. Der Prozeß des Kommunikationsüberwachungs-Untersystems 110 besteht im Nehmen abgehender Nachrichten 140 von der Kommunikations-Logdatei 126 (beispielsweise des abgehenden Status-Datensatzes 138A oder des abgehenden Daten-Datensatzes 138B, die durch das Bestätigungs-Untersystem 108 erzeugt werden) und im Ausgeben von ihnen zur externen Anwendung, die eine eingegebene Nachricht 132 sendete. Dieser Prozeß ist nur für Online-Benutzer. Eine eingegebene Stapelverarbeitung wird beim bevorzugten Ausführungsbeispiel der Erfindung durch das Schnittstellensystem 100 nicht bestätigt. Es sollte jedoch beachtet werden, daß es innerhalb des Transaktionsverarbeitungssystems 180 für die Anwendung ABAP Schemen gibt, um eine abgehende Datenübertragung zu erzeugen, die als Bestätigung funktioniert.
Ein Blockdiagramm der abgehenden Funktion ist in Fig. 8 gezeigt. Das Kommunikations-Untersystem 114 und das Kommunikationsüberwachungs-Untersystem 110 verarbeiten abgehende Steuerdatensätze 138 vom Bestätigungs-Untersystem 108. Diese enthalten abgehende Status-Datensätze 138A und abgehende Daten- Datensätze 138B. Ein abgehender Status-Datensatz 138A resultiert in einer abgehenden Statusnachricht 140A, die einfach eine Anfangsblocknachricht ohne Daten ist. Die abgehende Statusnachricht 140A ist analog zu einer Empfangsbestätigung vom US-Postservice. Sie zeigt an, daß eine Eingangsnachricht 132 empfangen wurde, und zeigt an, ob eine Verarbeitung erfolgreich oder fehlerhaft endete. Ein abgehender Daten-Datensatz 138B resultiert in einer abgehenden Datennachricht 140B, die eine vollständige Nachricht mit einem Anfangsblock und Daten ist.
Wenn das Zielortsystem ein Stapelverarbeitungssystem ist, wird der abgehende Daten-Datensatz 832 zu einer Abgangs-Logdatei 804 geschrieben, und ein ausgegebener Steuerdatensatz 834 wird zum Status-Untersystem 106 für ein Hinzufügen zur Abgangs-Logdatei 804 übertragen. Dann wird ein Strom von Jobsteuersprache(JCL)-Angaben zu einer internen Leseeinheit übertragen, die innerhalb eines MVS- Betriebssystems existiert, das als Host für den CICS-Bereich fungiert. Die JCL- Angaben initiieren einen Schritt zum Laufenlassen eines Stapelverarbeitungsprogramms innerhalb des MVS, um die Daten von der Logdatei 122 zu extrahieren und eine sequentielle Datei zu erzeugen. Die sequentielle Datei existiert auf einer Festplatte und wird in einem Stapel ohne Index erzeugt. Die Daten werden dann zum Zielortsystem unter Verwendung eines Stapelverarbeitungs-Datenbewegers übertragen. Obwohl der gesamte JCLprozeß außerhalb des Schutzumfangs des Schnittstellensystems 100 ist, verwendet er die Abgangs-Logdatei 804. Der Stapel- JCL-Strom enthält auch einen Endschritt zum Mitteilen zu dem Schnittstellensystem 100, daß die Übertragung beendet worden ist. Der Zweck davon besteht im Beenden des oben erzeugten Ausgangs-Steuerdatensatzes 834. Der aktive Ausgangsdatensatz 834 wird in diesem Fall nur zum Zulassen verwendet, daß eine Störungssuche auf eine Weise ausgeführt wird, die identisch zu Online- Ausgabekommunikationen ist.
Wenn das Zielortsystem ein Onlinesystem ist, werden ein oder mehrere Ausgangsdaten-Datensätze 832 zur Abgangs-Logdatei 804 geschrieben, und ein Ausgangs-Steuerdatensatz 834 wird genauso erzeugt, wie es oben für die Stapelverarbeitung erfolgt. Dann werden die Daten über entweder ein LU6.2- oder ein LU6.1-Protokoll vom Schnittstellensystem 100 übertragen. Die Logik zum Kommunizieren mit anderen COCS-Bereichen (LU6.1-Protokoll) unterscheidet sich etwas von jener, die unten für Abgangsprozesse beschrieben ist (LU6.2). Diese Protokolle sind lndustrie-Standardprotokolle. Jedoch sind die Unterschiede nicht wesentlich zum Verstehen des Datenflusses.
Kommunikationsaufgaben können eine signifikant längere Zeit zur Ausführung brauchen als die anderen Prozesse im Schnittstellensystem. Daher ist es wünschenswert, daß mehrere Kommunikationsaufgaben gleichzeitig ausgeführt werden. Aufgrund der Fähigkeit, mehrere gleichzeitige Kommunikationsaufgaben zu haben, und der Tatsache, daß nur eine Kommunikationsaufgabe für einen spezifischen Zielort zu einem Moment existieren kann, ist es nötig, daß das Kommunikationsüberwachungs-Untersystem 110 die Fähigkeit zum Managen mehrere Kommunikationsaufgaben hat.
In diesem Abschnitt des Patentdokuments wird die Abgangsfunktion gemäß der vorliegenden Erfindung beschrieben. Der Prozeß zum Senden von Datennachrichten vom Transaktionsverarbeitungssystem könnte ohne Verwendung des Schnittstellensystems 100 gemäß der vorliegenden Erfindung behandelt werden. Jedoch wird die Abgangsverarbeitung gemäß einem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung unter Verwendung des Schnittstellensystems 100 durchgeführt. Dies läßt zu, daß eine Schnittstellenbildung mit externen Anwendungen unter Verwendung eines einzigen Verfahrens durchgeführt wird (desselben Verfahrens, wie bei den Statusbestätigungen von Eingangsnachrichten), und daß eine einzelne Steuerstelle vorgesehen wird.
Fig. 9 ist ein Flußdiagramm, das eine Übersicht über die bei einer Abgangsverarbeitung beteiligten Schritte auf hoher Ebene darstellt. Nimmt man nun Bezug auf die Fig. 8 und 9, wird die Abgangsverarbeitung gemäß der vorliegenden Erfindung beschrieben.
In einem Schritt 902 wird ein Geschäftsanwendungsprogramm im Transaktionsverarbeitungssystem 180 durch irgendein Ereignis getriggert. Das Ereignis kann ein Anwender an einem Terminal sein, der eine spezifische Transaktion laufen läßt, die dazu führt, daß ein Ausgangsdaten-Datensatz 832 erzeugt wird, oder kann irgendeine andere Transaktion laufen lassen, die als Teil ihrer Aufgabe einen Ausgangsdaten-Datensatz erzeugt. Das Ereignis kann auch die Ankunft einer Eingangsnachricht sein, die ein derartiges Ereignis triggert.
Gemäß einem Ausführungsbeispiel der vorliegenden Erfindung ist die Abgangs- Logdatei 804 des Schnittstellensystems 100 eine separate logische Datenbank von der Eingangs-Logdatei 122, aber sie sind dieselbe physikalische Datei. Bei einem alternativen Ausführungsbeispiel können die Abgangs-Logdatei 804 und die Logdatei 122 tatsächlich separate physikalische Dateien sein. Ausgangsdaten- Datensätze 832 werden durch das Geschäftsanwenderprogramm mit einem Datentyp von PO (Null), einer eindeutigen Stapelverarbeitungsnummer und einer seriellen Nummer in ansteigender Reihenfolge erzeugt.
Wenn die Erzeugung der Ausgangsdaten-Datensätze 832 beendet ist, wird ein Ausgangs-Steuerdatensatz 834 durch das Geschäftsanwendungsprogramm erzeugt und wird zum Status-Untersystem 106 für ein Hinzufügen zur Abgangs- Logdatei 804 geführt. Der Ausgangs-Steuerdatensatz 834 ist nur ein Anfangsblock. Er ist eine Datei vom Typ PM und er enthält eine Zahl für die Anzahl von Ausgangsdaten-Datensätzen 832. Alternativ können die Daten dann, wenn ein einzelner Ausgangsdaten-Datensatz 832 die gesamte Nachricht aufweist, im Ausgangs- Steuerdatensatz 834 enthalten sein, so daß keine Ausgangsdaten-Datensätze 832 zur Abgangs-Logdatei 804 geschrieben werden.
In einem Schritt 904 wird auch der Ausgangs-Steuerdatensatz 834 in der Schnittstellensystem-Ausgangs-Logdatei 308 gespeichert. Sobald der Ausgangs- Steuerdatensatz 834 an der Abgangs-Logdatei 804 vorhanden ist, ist das Schnittstellensystem 100 frei, zu versuchen, Ausgangsdaten-Datensätze 832 zum Empfänger auszugeben.
In einem Schritt 906 startet das Überwachungs-Untersystem 112 das Bestätigungs-Untersystem 108 und das Kommunikationsüberwachungs-Untersystem 110. In einem Schritt 908 durchsucht das Bestätigungs-Untersystem 108 die Ausgangs- Logdatei 308 (und die in Fig. 1 gezeigte und oben in bezug auf die Fig. 1 und 7 diskutierte Logdatei 122). Das Bestätigungs-Untersystem 108 durchsucht alle aktiven Ausgangs-Steuerdatensätze vom Typ PM (Abgang) mit einem Schnittstellensystem-Statuscode mit einem Wert kleiner als 6. Wie es oben diskutiert ist, ist der Datensatz dann, wenn der Schnittstellensystem-Statuscode kleiner als 6 ist, nicht durch das Bestätigungs-Untersystem 108 verarbeitet worden.
Das Bestätigungs-Untersystem 108 unterzieht den Schnittstellensystem- Statuscode einem Updaten auf 8 oder 9 und ändert den Dateientyp zu PS, was anzeigt, daß der Ausgangs-Steuerdatensatz 834 beendet ist. Durch Ändern des Dateientyps wird der beendete Ausgangs-Steuerdatensatz 834 aus dem Pool der aktiven Ausgangs-Steuerdatensätze 834 bewegt, was die Anzahl von Ausgangs- Steuerdatensätzen 834 minimiert, die jedesmal durchsucht werden, wenn der Prozeß ausgeführt wird. Das Bestätigungs-Untersystem 108 erzeugt einen Abgangs- Steuerdatensatz 138 und ordnet ihn in einer Kommunikations-Logdatei 126 an. Jeder Abgangs-Steuerdatensatz 138 enthält Daten, die einen Zielortknoten anzeigen, zu welchem die Nachricht zu senden ist.
In einem Schritt 910 durchsucht das Kommunikationsüberwachungs-Untersystem 110 die Kommunikations-Logdatei 126 auf der Suche nach dem Abgangs- Steuerdatensatz 138. Für jeden Zielortknoten startet das Kommunikationsüberwachungs-Untersystem 110 einen Kommunikationsprozeß im Kommunikations- Untersystem 114.
In einem Schritt 912 bildet das Kommunikations-Untersystem 114 eine Verbindung mit jedem Zielortknoten. Das Kommunikations-Untersystem 114 liest einen Abgangs-Steuerdatensatz 148 von der Kommunikations-Logdatei 126 aus, und dann, wenn sie anwendbar sind, Ausgangsdaten-Datensätze 832 von der Abgangs- Logdatei 308, und sendet Abgangsnachrichten 140 zur externen Anwendung.

3.4.1 Kommunikationsüberwachungs-Untersystem und prozeß

Fig. 14 ist ein Flußdiagramm, das den Kommunikationsüberwachungsprozeß darstellt. Gemäß Fig. 14 wird in einem Schritt 1422 das Kommunikationsüberwachungs-Untersystem 110 durch das Überwachungs-Untersystem 112 gestartet. Das Kommunikationsüberwachungs-Untersystem 110 durchsucht die Kommunikations-Logdatei 126. Wenn keine Abgangs-Steuerdatensätze 138 mehr in der Abgangs-Kommunikations-Logdatei 126 existieren (Schritt 1424), wird der Abgangskommunikationsprozeß beendet (Schritt 1425). Wenn jedoch Abgangs- Steuerdatensätze 138 gefunden werden, fährt der Prozeß bei einem Schritt 1426 fort. Im Schritt 1426 prüft das Kommunikationsüberwachungs-Untersystem 110 den Master-Steuerdatensatz 154 des Schnittstellensystems 100, um zu sehen, ob die Anzahl von Kommunikationsaufgaben eine durch die Installation definierte Grenze überschritten hat. Wenn es so ist, endet der Prozeß beim Schritt 1425. Diese Grenze läßt zu, daß die Installation verhindert, daß zu viele lang laufenden Kommunikationsaufgaben zur gleichen Zeit ausgeführt werden und Betriebsmittel blokkieren. Wenn sie nicht die maximale Anzahl von Aufgaben überschritten hat, fährt der Prozeß bei einem Schritt 1428 fort.
Im Schritt 1428 wird eine Prüfung durchgeführt, um zu sehen, ob eine Kommunikationsaufgabe schon eine Ausführung für den spezifizierten Zielortknoten durchführt. Wenn bereits eine Aufgabe für diesen Knoten existiert, fährt der Prozeß mit einem Durchsuchen der Kommunikations-Logdatei 126 in einem Schritt 1422 fort, und sucht andere Abgangs-Steuerdatensätze 138, für die es erforderlich ist, daß eine Ausgangsnachricht 140 gesendet wird. Wenn gerade keine Aufgabe durchgeführt wird, fährt der Prozeß in einem Schritt 1430 fort.
Im Schritt 1430 prüft der Kommunikationsüberwachungsprozeß, um zu sehen, ob die Anzahl von erneuten Versuchen für diese Nachricht eine durch die Installation definierte "Verlangsamungszahl" überschritten hat. Wenn keine Zielortanwendung verfügbar ist, läßt dies zu, daß das Schnittstellensystem 100 das externe System mit einer viel niedrigeren Frequenz erneut versucht, um dadurch zuzulassen, daß andere Zielorte eine Chance haben, ohne dabei die maximale Aufgabenzahl zu überschreiten.
Wenn die Verlangsamungszahl überschritten worden ist, prüft der Prozeß im Schritt 1432, um zu sehen, ob es die richtige Zeit dafür ist, zu versuchen, erneut eine Verbindung zum Zielort herzustellen. Wenn es entweder die geeignete Zeit ist oder die Verlangsamungszahl nicht überschritten worden ist, wird in einem Schritt 1434 eine Prüfung durchgeführt, um zu sehen, ob die Anzahl von erneuten Versuchen eine spezifizierte Grenze überschritten hat, die beim bevorzugten Ausführungsbeispiel 3000 Versuche ist. Wenn jedoch die Verlangsamungszahl überschritten worden ist (Schritt 1430) und daher die Frequenz nicht erniedrigt werden kann, und es nicht die Zeit zum Versuchen im Verlangsamungsbetrieb ist (Schritt 1432), wird in einem Schritt 1438 der Abgangs-Steuerdatensatz 138 erneut geschrieben und ein Zähler, der die Anzahl von erneuten Versuchen anzeigt (Zähler 802 für erneute Versuche) wird inkrementiert. An dieser Stelle macht die Verarbeitung beim Schritt 1422 weiter.
Wenn die maximale Anzahl von erneuten Versuchen im Schritt 1434 überschritten worden ist, wird in einem Schritt 1436 der Abgangs-Steuerdatensatz von der Kommunikations-Logdatei 126 gelöscht und der Status des beendeten Steuerdatensatzes 148 an der Logdatei 122 wird einem Updaten unterzogen, um anzuzeigen, daß der Kommunikationsversuch fehlgeschlagen ist.
Wenn der zu bedienende Datensatz eine Bestätigung einer endlichen Kette ist und er entweder ein F- oder ein M-Datensatz ist, wird er temporär übersprungen. Wenn er der F-Datensatz ist, wird sein Schlüssel gespeichert, bis der L-Datensatz gefunden wird, und dann wird der Schlüssel mit dem L-Datensatz eingeschlossen, wenn er zum Kommunikationsprozeß geführt wird.
Wenn die Anzahl von erneuten Versuchen die maximale Grenze nicht überschritten hat (Schritt 1434), wird in einem Schritt 1440 ein Kommunikations-Untersystem 114 gestartet, und ein Flag wird gesetzt, um anzuzeigen, daß gerade eine Aufgabe für diesen Zielort in Arbeit ist.

3.4.2 Kommunikations-Untersystem und prozeß

Die Fig. 10 und 11 sind Flußdiagramme, die Details des Kommunikations- Untersystems 114 und seinen Prozeß darstellen.
Gemäß Fig. 10 empfängt das Kommunikations-Untersystem 114 dann, wenn es in einem Schritt 1002 aufgerufen wird, eine Zielortadresse. Diese Adresse sitzt in einem übergebenen Datenbereich in einem Speicher, der durch das CICS vorgesehen ist. Diese Adresse kann entweder eine indirekte Zielortadresse oder eine direkte Zielortadresse sein. Eine direkte Adresse ist ein aktueller Knotennamen, der in einer CICS-Tabelle enthalten ist. Eine indirekte Adresse ist ein logischer Zielort, der eine oder zwei reale alternative Adressen haben kann.
In einem Schritt 1003 durchsucht das Kommunikations-Untersystem 114 die Abgangskommunikations-Datei 126 und such nach einem Abgangsstatus-Datensatz 138A oder einem Abgangsdaten-Datensatz 138B mit einer Zielortadresse, die mit der im Schritt 1002 empfangenen Adresse übereinstimmt. Bei einem bevorzugten Ausführungsbeispiel werden die Abgangs-Datensätze 138A, 138B in der Kommunikations-Logdatei 126 in der Reihenfolge ihrer Zielortadresse gespeichert.
In einem Schritt 1004 bestimmt das Kommunikations-Untersystem 114, ob ein Zielortfeld ein direktes oder ein indirektes Moden-Flag enthält, durch das Vorhandensein eines Sternchens als das erste Zeichen der Adresse. Das Vorhandensein eines Sternchen-Zeichens zeigt an, daß die Adresse indirekt oder logisch ist. In diesem Fall können zwei Zielortknoten, nämlich ein primärer und ein sekundärer (oder Hintergrund-) Knoten in anderen Feldern im Steuerdatensatz-Anfangsblock spezifiziert sein.
Wenn die Adresse indirekt ist, versucht der Prozeß in einem Schritt 1006 zuerst eine Verbindung mit der primären Knotenadresse herzustellen. Wenn ein solcher Versuch nicht erfolgreich ist, dann versucht der Prozeß in einem Schritt 1008, eine Verbindung mit der sekundären Knotenadresse herzustellen.
Wenn der Prozeß im Schritt 1004 bestimmt, daß die Adresse direkt (real) ist, ist das Adressenfeld in einem Schritt 1010 selbst eine physikalische Knotenadresse, und der Kommunikationsprozeß versucht unter Verwendung dieser Adresse eine Verbindung mit dem Zielort herzustellen.
Im Schritt 1006 oder 1008 oder 1010 versucht das Kommunikations-Untersystem 110, eine Verbindung zum externen Prozeßsystem zu bilden. Dies wird durch Verwendung der geeigneten Befehle für das Protokoll durchgeführt, das verwendet wird. Wenn die Verbindung zum externen Computersystem nicht erfolgreich gebildet wird, fährt der Prozeß bei einem Schritt 1102 fort.
Im Schritt 1102 wird dann, wenn das Schnittstellensystem 100 fehlgeschlagen hat, eine Verbindung zu bilden, eine Zahl der Anzahl von erneuten Versuchen um 1 inkrementiert. Wenn diese Zahl eine zuvor spezifizierte Schwelle (beispielsweise 3000) überschreitet (Schritt 1103), wird der Abgangs-Steuerdatensatz 138 von der Abgangsdaten-Datei 126 in einem Schritt 1104 gelöscht. Gemäß einem Ausführungsbeispiel der vorliegenden Erfindung, das eine Zykluszeit von 45 Sekunden für das Überwachungs-Untersystem 112 verwendet, würde dies etwa 37,5 Stunden dauern.
Wenn jedoch die Zahl der Anzahl von erneuten Versuchen kleiner als die Schwelle ist, wird der Abgangs-Steuerdatensatz 138 an der Abgangskommunikations-Datei 126 in einem Schritt 1106 einem Updaten unterzogen.
Wenn das Kommunikations-Modul 110 im Schritt 1006,1008 oder 1010 erfolgreich eine Verbindung zur Zielortadresse herstellt, fährt der Prozeß bei einem Schritt 1108 fort. Im Schritt 1108 wird dann, wenn die Verbindung erfolgreich ist, ein Sendeprozeß initiiert. Es gibt drei mögliche Fälle für den Sendeprozeß. Es gibt einen Fall einer großen Nachricht, einen Fall einer Kettennachricht und einen Fall für eine selbstenthaltende Nachricht.
In einem Schritt 1110 schaut das Kommunikationsprozeß-Modul 110 auf Flags des Abgangs-Steuerdatensatzes 138 in der Abgangskommunikations-Datei 126, um zu bestimmen, ob ein Datensatz der letzte Datensatz einer Kette einer Kettennachricht ist. Wenn ein KETTENPOST-Flag L ist, zeigt dies an, daß dies das letzte oder nur der Abgangs-Steuerdatensatz 138 einer Bestätigung einer endlichen Kette in der Abgangskommunikations-Datei 126 ist.
Wenn der gegenwärtige Datensatz der letzte Datensatz einer endlichen Kette ist, fährt der Prozeß bei einem Schritt 1112 fort.
Im Schritt 1112 durchsucht der Prozeß die Kommunikations-Logdatei 126, um alle Nachrichten der Kettenpostnachricht in der richtigen Reihenfolge zu erhalten und zu senden. Der Schlüssel vom F-Datensatz vom Anfang der Kette wird zum Starten einer Durchsuchung verwendet, und die F-, M- und L-Anfangsblöcke plus ein Längenfeld werden gesendet. Wenn einem L-Datensatz begegnet wird, wird eine Option eingestellt, um einen Empfang zu bestätigen, und zwar unter Verwendung von LU6.2-Protokollen.
Wenn der Datensatz kein L-Datensatz in einer FML-Kette ist, wird in einem Schritt 1114 ein Abgangs-Steuerdatensatz 138 von der Kommunikations-Logdatei 126 zum Kommunikations-Untersystem 114 gesendet.
Wenn ein Flag für POST-GROSSER-MENGE gesetzt ist, zeigt dies an, daß der Datensatz in der Abgangs-Logdatei 126 eine Ansammlung von Ausgangs- Datensätzen 832 an der Schnittstellensystem-Abgangs-Logdatei 308 darstellt.
Wenn dies eine Gruppe von Nachrichten großer Menge ist, werden die Ausgangsdaten-Datensätze 832 von der Logdatei 308 in einem Schritt 1116 gesendet. Im Schritt 1104 wird dann, wenn der Abgangs-Steuerdatensatz 138 in der Abgangskommunikations-Datei 126 eine selbstenthaltende Nachricht ist, oder dann, wenn die Ausgangsdaten-Datensätze 832 für eine Gruppe großer Menge gesendet worden sind, wird die Struktur der Datensätze der Ausgangs-Logdatei 308 mit Anfangsblock und Datenteilen mit einem BESTÄTIGUNGS-Parameter gesendet.
Wenn eine Ausgangsnachricht 140 fehlerfrei gesendet wird, wird der Abgangs- Steuerdatensatz 138 von der Kommunikations-Logdatei 126 gelöscht. Zusätzlich wird der beendete Abgangs-Steuerdatensatz 138 (vom Typ PS) an der Datei 804 der Kommunikations-Logdatei 126 gelesen, und sein Status wird geändert, um anzuzeigen, daß er übertragen worden ist. Das Kommunikationsprozeß-Modul 110 fährt ein Durchsuchen der Abgangs-Kommunikationsdatei 126 bei einem Schritt 1103 und ein Verarbeiten weiterer Datensätze fort.
Wenn beim Senden einer Kommunikation einem Fehler begegnet wird, wird ein Befehl, der AUSGABEFEHLER genannt wird, zur externen Anwendung unter Verwendung von LU6.2 gesendet, und ein Rücksprung-Code wird gesetzt, um einen nicht behebbaren Fehler anzuzeigen.
Wenn der Rücksprung-Code einmal gesetzt worden ist, um anzuzeigen, daß ein nicht behebbarer Fehler aufgetreten ist, wird eine Zahl der Anzahl von erneuten Versuchen um 1 inkrementiert. Wenn diese Zahl einmal die Schwelle von 3000 überschreitet, wird der Datensatz von der Abgangs-Kommunikationsdatei 126 gelöscht. Solange die Zahl kleiner als 3000 ist, wird der Datensatz an der Abgangs- Kommunikationsdatei 126 einem Updaten unterzogen. Ein Feld COM-TRAN wird auf hohe Werte im Durchsuchungsschlüssel gesetzt, so daß irgendwelche zurückbleibenden Datensätze vom selben Knoten übersprungen werden. Allgemein überträgt LU6.2 nicht tatsächlich Daten, bis es einen zum Senden verfügbaren vollen Puffer hat. Somit wird eine Verbindung tatsächlich nicht hergestellt, bis der erste Puffer zum Senden bereit ist, und daher kann das Schnittstellensystem 100 kein Anzeichen eines Fehlers empfangen, bis mehrere Befehle nach dem Befehl, der den Fehler verursachte. Es ist nicht praktisch, die Linie um jeden gesendeten Datensatz zu ziehen, so daß dann, wenn einem Fehler begegnet wird, beide Einheiten aus dem gesamten Stapel zurück sein werden.

4. Überwachungsprozeß

Wie es in diesem Patentdokument zuvor diskutiert ist, sorgt das Überwachungs- Untersystem 112 für Zeitabtastungen (Ereignisse), die zum Initiieren bestimmter Schnittstellensystemprozesse nötig sind. Fig. 15 ist ein Blockdiagramm auf hoher Ebene, das das Überwachungs-Untersystem 112 und seine Schnittstellen darstellt. Das Überwachungs-Untersystem 112 wird anfangs durch einen unten beschriebenen Hochfahrprozeß 1502 gestartet. Es untersucht dann Statusinformationen vom Transaktionsverarbeitungssystem 180, um zu bestimmen, ob sie verfügbar sind oder nicht. Der Überwachungsprozeß startet drei andere Prozesse, und zwar den Bestätigungsprozeß, der sofort gestartet wird, und den Triggerprozeß und den Kommunikationsüberwachungsprozeß, die beide nach einer Verzögerung von 5 Sekunden gestartet werden. Diese Verzögerungen geben dem Bestätigungsprozeß eine Chance zum Beenden seiner Aufgaben.
Fig. 16 ist ein Flußdiagramm, das die durch das Überwachungsprozeß-Modul beim Beenden seines Prozesses durchgeführten Schritte darstellt. Nun wird unter Bezugnahme auf die Fig. 8, 15 und 16 das Überwachungsprozeß-Modul beschrieben. In einem Schritt 1602 wird das Überwachungsprozeß-Untersystem 112 anfangs durch einen Hochfahrprozeß 1502 gestartet. Wenn das Überwachungsprozeß- Untersystem 112 gestartet ist, läuft es automatisch weiter, und zwar in einem regelmäßig zeitlich abgestimmten Intervall zum Selbststarten. Dieses zeitlich abgestimmte Intervall wird durch eine jeweilige Installation zuvor spezifiziert, und zwar unter Verwendung einer Transaktion "YSPM" im Transaktionsverarbeitungssystem 180, um eine Statusnachricht zum Statusprozeß 106 zu senden. Dieses Intervall wird in der Logdatei 122 gespeichert. Gemäß einem gegenwärtigen Ausführungsbeispiel der vorliegenden Erfindung beträgt die für das Zeitintervall zugeführte Anfangsvorgabe 45 Sekunden. Die "YSPM"-Transaktion wird zum Updaten des Master-Steuerdatensatzes 154 und zum Löschen eines unerwünschten Steuerdatensatzes 148 durch Senden eines Pseudo-Statuscodes verwendet.
In einem Schritt 1604 empfängt das Überwachungs-Untersystem 112 eine Datenbereichsnachricht 836, die entweder von der Hochfahraufgabe 1502 übergeben wird, oder von einer vorherigen Ausführung des Überwachungsprozesses. Die Datenbereichsnachricht 836 enthält Statusbytes von der vorherigen Ausführung des Überwachungs-Untersystems 112, welche mit den gegenwärtigen Werten der Statusinformationen verglichen werden, um Statusänderungen zu erfassen. Die Hochfahraufgabe 1502 übergibt immer binäre Null-Werte. Dies erzwingt eine Änderung bei den Statuswerten bei der ersten Ausführung des Überwachungs- Untersystems 112. Das Überwachungs-Untersystem 112 übergibt diese Werte zur nachfolgenden Ausführung. Die Statusbytes sind unten beschrieben.
In einem Schritt 1606 bestimmt das Überwachungs-Untersystem 112, ob gerade konkurrierende Aufgaben laufen. Dies wird dadurch erreicht, daß das Überwachungs-Untersystem 112 das Schnittstellensystem 100 nach Daten über sich selbst (das Überwachungs-Untersystem 112) und über den Triggerprozeß 104 und das Bestätigungs-Untersystem 108 befragt. Wenn eine weitere Kopie des Überwachungsprozesses gegenwärtig läuft (Schritt 1608), endet diese neue Kopie. Wenn entweder der Triggerprozeß oder der Bestätigungsprozeß gerade läuft, schichtet sich das Überwachungs-Untersystem 112 in einem Schritt 1610 selbst um.
Wenn gerade kein konkurrierender Prozeß läuft, testet das Überwachungs- Untersystem 112 in einem Schritt 1602 den Wert von vier Statusbytes. Das Überwachungs-Untersystem 112 bildet eine Adressierbarkeit zu einem Transaktionsverarbeitungssystem-Datenbereich im hohen Speicher, wo die Statusbytes durch Verwenden eines Standardbefehls gespeichert werden, der durch das Host- Transaktionsverarbeitungssystem (CICS) zugeführt wird.
Die geprüften Statusse sind folgende:
Ist das Transaktionsverarbeitungssystem nicht aktiv;
Ist die Transaktionsverarbeitungssystem-Update-Aufgabe nicht aktiv;
Initialisiert das Transaktionsverarbeitungssystem; und
Ist das Transaktionsverarbeitungssystem nur ein "Not"-System?
Wenn einer der Statusse wahr ist, oder wenn entweder die Logdatei 122 oder die Kommunikations-Logdatei 126 geschlossen ist, springt das Überwachungs- Untersystem 112 zum Ende des Prozesses und schichtet sich selbst um.
In einem Schritt 1614 plant das Überwachungs-Untersystem 112 eine Initiierung des Bestätigungsprozesses, des Triggerprozesses und des Kommunikationsprozesses. Bei einem bevorzugten Ausführungsbeispiel plant das Überwachungs- Untersystem 112 zuerst, daß das Bestätigungs-Untersystem 108 eine Ausführung sofort durchführt. Das Überwachungs-Untersystem 112 plant dann den Triggerprozeß 104 und daß das Kommunikationsüberwachungs-Untersystem 110 fünf Sekunden später eine Ausführung durchführt. Die Verzögerung von fünf Sekunden läßt zu, daß das Bestätigungs-Untersystem 108 in einem Fall fertig wird, in dem es irgendeine zusätzliche Arbeit für den Triggerprozeß 104 oder das Kommunikationsüberwachungs-Untersystem 110 erzeugt. Der Triggerprozeß 104 und das Bestätigungs-Untersystem 108 können gleichzeitig eine Ausführung durchführen. Im Schritt 1610 plant das Überwachungs-Untersystem 112 für sich selbst, daß es wieder läuft. Statusbytes von der aktuellen Ausführung werden zur nächsten Ausführung weitergeleitet. Die Zeit, zu der das Überwachungs-Untersystem 112 gemäß dem Zeitplan wieder läuft, wird aus dem Zeitintervall bestimmt, das im Master- Steuerdatensatz der Logdatei 122 gespeichert ist.
In einem Schritt 1616 werden die Statusbytes von der vorherigen Ausführung mit den Statusbytes für die aktuelle Ausführung verglichen. Wenn diese Statusbytes unterschiedlich sind, ist der Status geändert worden, und eine Nachricht wird zur Schnittstellensystem-Logdatei 122 geschrieben, was anzeigt, daß die Änderung aufgetreten ist. Dies ist nur ein lnformationsschritt und wird zum Ermöglichen einer Störungssuche verwendet.

5. Hochfahren des Schnittstellensystems

Das Schnittstellensystem gemäß der vorliegenden Erfindung soll ein selbststartendes System sein. Es gibt keine zum CICS externen Prozeduren, denen gefolgt werden muß. Dafür existiert ein Hochfahrmodul und wird durch die Programmladetabelle (PLT) im CICS gesteuert.
Es ist zu beachten, daß es keine spezifische Abschaltlogik für das Schnittstellensystem gemäß der vorliegenden Erfindung gibt. Während normaler Operationen überwacht das Schnittstellensystem den Status des Transaktionsverarbeitungssystems. Wenn das Transaktionsverarbeitungssystem keine Verarbeitung durchführt, geht das Schnittstellensystem in einen Schlafmodus über. In diesem Modus überwacht das Schnittstellensystem nur das Transaktionsverarbeitungssystem und wartet darauf, daß es wiederum eine Verarbeitung beginnt.
Fig. 17 ist ein Flußdiagramm, das die Schritte darstellt, die durchgeführt werden, wenn das CICS hochfährt. Nimmt man nun auf die Fig. 1 und 17 Bezug, wird in einem Schritt 1702 das Hochfahren des CICS initiiert. Im Schritt 1703 werden PLT- Tabelleneinträge für das Hochfahren verarbeitet. Der Eintrag des Schnittstellensystems 110 für einen Prozeß dient für eine Transaktion mit dem Namen POS1.
In einem Schritt 1703 führt die Transaktion POS1 eine Ausführung durch. Beim Ausführen startet POS1 in einem Schritt 1704 eine Transaktion mit dem Namen POS2 (Schritt 1704). Es ist zu beachten, daß dann, wenn eine Transaktion, die durch die PLT gestartet ist, keine erfolgreiche Ausführung durchführt, daß CICS nicht hochfahren wird. Daher wird in POS1 die minimal notwendige Verarbeitung durchgeführt.
Eine Ausführung von POS2 ist ein mehrstufiger Prozeß. Zuerst sperrt POS2 in einem Schritt 1702 das Eingabeempfangs-Untersystem 102. Als Ergebnis werden keine Abgangsnachrichten 132 verarbeitet, während die Logdatei 122 für ein Hochfahren verarbeitet wird. Dies sperrt tatsächlich eher die Module hinter den Transaktionen, als daß es die Transaktionen selbst sperrt.
In einem Schritt 1706 bestimmt ein Hochfahrprogramm den Namen eines Bereichs, in dem es eine Ausführung durchführt, und schreibt diesen Namen zu einer temporären Speicherwarteschlange. Dies wird derart durchgeführt, daß das Stapelverarbeitungsempfangsmodul des Eingabeempfangs-Untersystems 102 den Bereichkennt, in welchem es eine Ausführung durchführt. Bei alternativen Ausführungsbeispielen könnte dies direkt durch das Stapelverarbeitungsempfangs- Modulprogramm durchgeführt werden.
In einem Schritt 1707 werden alle Übereinstimmungsdatensätze 152 an der Übereinstimmungs-Datei 124 gelöscht. Als Ergebnis wird die Übereinstimmungs-Datei 124 dann erneut gebildet, wenn das Bestätigungs-Untersystem 108 zum ersten Mal eine Ausführung durchführt.
In einem Schritt 1708 lädt das Hochfahrprogramm den Master-Steuerdatensatz 154 von der Logdatei 122. Alternativ dazu fährt die Ausführung dann, wenn kein Master-Steuerdatensatz 154 gefunden wird, beim Schritt 1710 fort. Wenn kein Master-Steuerdatensatz 154 gefunden wird, wird ein neuer PC-Datensatz unter Verwendung von Vorgabewerten erzeugt. Dies ist diesbezüglich von Bedeutung, daß eine automatische Stapelnumerierung und serielle Nummern von Null anfangen werden, und die eindeutigen Benutzer-IDs, die im Triggerprozeß erzeugt werden, insgesamt gestartet werden. Wenn Datensätze an der Transaktionsverarbeitungssystem-Logdatei von vorherigen Sessions existieren, gibt es eine sehr geringe Wahrscheinlichkeit, daß sich Konflikte aufgrund doppelter Benutzer-IDs entwikkein können. Der Grund dafür, daß die Wahrscheinlichkeit gering ist, daß ein Konflikt auftritt, besteht darin, daß dieselbe Stapelverarbeitungsnummer und serielle Nummer gemeinsam benutzt werden müssen. In einem solchen Fall würde der alte Datensatz durch den Bestätigungsprozeß gefunden werden, bevor die Transaktion tatsächlich läuft.
In einem Schritt 1710 prüft der Hochfahrprozeß POS2 das Vorhandensein eines aktiven Zeitgeber-Steuerdatensatzes 160 für einen Anwendungszeitgeber. Wenn keiner existiert, erzeugt POS2 einen.
In einem Schritt 1711 durchsucht der Hochfahrprozeß POS2 die Logdatei 122 nach aktiven Steuerdatensätzen 148, die gerade verarbeitet wurden, als das System ausschaltete. Wenn es geeignet ist, wird ein Datensatzstatus rückgesetzt, um zu erzwingen, daß eine Triggeraufgabe einen Prozeß wiederaufnimmt. Wenn ein regulärer Datensatz oder ein Kettendatensatz mit einem Status von 3 oder 4 gefunden werden, wird von ihnen angenommen, das sie nicht beendet haben. In diesem Fall wird ein ODC TD-Warteschlangenpuffer erneut übertragen werden. Dies wird dadurch erreicht, daß der Status des aktiven Zeitgeber-Steuerdatensatzes 160 zurück auf einen Wert von "2" gesetzt wird, was veranlaßt, daß der Triggerprozeß den Datensatz als auswählbar zur Übertragung bei seiner nächsten Ausführung ansieht.
Wenn eine Nachricht großer Menge gefunden wird und ihr ABBRUCH_FLAG nicht gesetzt ist, wird ihr Statuswert geprüft. Wenn ihr Statuswert 3 ist, wird angenommen, daß die Nachricht niemals die Stufe erreicht hat, wo die Stapelverarbeitungsdatei gebildet wurde. In diesem Fall muß die ODC durch Rücksetzen ihres Status auf 2 erneut übertragen werden. Wenn jedoch der Status der Postnachricht großer Menge 4 ist, wird angenommen, daß der Stapel gebildet worden ist, und ein Neustartbefehl wird ausgegeben.
In einem Schritt 1712 werden die Eingabeprozesse durch Freigeben der Module für diese Prozesse erneut freigegeben und das Überwachungs-Untersystem 112 wird gestartet.

6. Abschalten

Wie es zuvor angegeben ist, gibt es keine formelle Abschaltprozedur für das Schnittstellensystem gemäß der vorliegenden Erfindung. Das Schnittstellensystem gemäß der vorliegenden Erfindung ist derart entworfen, daß es sich während eines normalen Abschaltens des CICS selbst automatisch abschaltet. Es ist jedoch ein Verfahren zum Abhalten des Schnittstellensystems von einem Übertragen von irgendwelcher weiterer neuer Arbeit zum Transaktionsverarbeitungssystem in Vorbereitung für sein Abschalten oder seine nächtlichen Zyklen enthalten. Dies läßt zu, daß das Transaktionsverarbeitungssystem eine gerade durchgeführte Arbeit beendet, ohne daß irgend etwas erneut gestartet wird.
Das automatische Abschalten des Schnittstellensystems gemäß der vorliegenden Erfindung wird allgemein beschrieben. Wenn eine Transaktionsverarbeitung eine Verarbeitung aufhört oder wenn die Update-Aufgabe aufhört, stoppt das Überwachungs-Untersystem 112 des Schnittstellensystems 100 ein Planen eines Triggerprozesses 104, des Bestätigungs-Untersystems 108 und des Abgangskommunikations-Untersystems 114. Jedoch fährt das Eingabeempfangs-Untersystem 102 mit einer Ausführung fort, Nachrichten an der Logdatei 122 zu empfangen und zu speichern.
Wenn es gewünscht ist, das Schnittstellensystem 100 von einem Übertragen neuer Arbeit zum Transaktionsverarbeitungssystem 180 in Vorbereitung für ein Abschalten abzuhalten, wird ein Stapelverarbeitungsjob unter Verwendung der SYSB- Einrichtung zum Senden einer Nachricht zur Triggeraufgabe von "BLOCK P05" und "UNBLOCK P05" laufen gelassen. Dies veranlaßt, daß ein Flag im Master-Steuerdatensatz gesetzt oder gelöscht wird, und der Triggerprozeß 104 erfaßt den Wert dieses Flags und handelt entsprechend.

7. Dateireorganisierung

Im Schnittstellensystem 100 gemäß der vorliegenden Erfindung wird ein Stapelverarbeitungszyklus zum Erhalten der Logdatei 122 verwendet, und zum Löschen unerwünschter Datensätze auf einer periodischen Basis. Neuorganisierungsschritte sind abhängig von den verwendeten Dateizugriffsverfahren. Bei einem Ausführungsbeispiel wird das VSAM-Dateizugriffsverfahren von IBM verwendet; jedoch sind andere Dateizugriffsverfahren geeignet und würden andere Neuorganisierungsanforderungen haben. Gemäß einem Ausführungsbeispiel soll die Stapelverarbeitungsdatei auf einer täglichen Basis laufen, jedoch könnte dieses Intervall zur Anpassung an alternative Umgebungen geändert werden.
Der Stapelverarbeitungszyklus ist in zwei Jobsteuersprachströme aufgeteilt. Der erste Job verarbeitet sowohl die Logdatei 122 als auch die Abgangskommunikations-Datei 126. Der zweite Stapelverarbeitungsjob verarbeitet nur die Logdatei 122. Es gibt keine explizite Neuorganisierung für die Übereinstimmungsdatei 124.
Die Übereinstimmungsdatei 124 ist so entwickelt, daß sie selbsterhaltend ist, online gehalten wird und immer beim Hochfahren des CICS gelöscht wird. Die Abgangskommunikations-Datei 126 wird einfach ausgelagert und erneut importiert, um zuzulassen, daß freier Raum neu verteilt wird, wobei die Auslagerung als Rücklage gehalten wird.
Fig. 18 ist ein Flußdiagramm, das die Schritte darstellt, die beim Stapelverarbeitungszyklus beteiligt sind, der zum Unterhalten der Logdatei 122 verwendet wird. Unter Bezugnahme auf die Fig. 1 und 18 wird nun dieser Prozeß beschrieben. In einem Schritt 1802 werden alle temporären Datensätze an der Logdatei 122 gelöscht. In einem Schritt 1804 werden die Logdatei 122 und die Abgangskommunikations-Datei 126 zu einem sequentiellen Datensatz exportiert.
In einem Schritt 1806 wird die Logdatei 122 durch ein Stapelverarbeitungs- ABAP/4-Programm neu organisiert. Diese Neuorganisation enthält ein Löschen von Datensätzen, die nicht mehr benötigt werden. Dieser Prozeß wird unten unter Bezugnahme auf Fig. 19 weiter beschrieben.
In einem Schritt 1808 wird die sequentielle Datei vom Export der Abgangskommunikations-Datei 126 zum erneuten Speichern der Abgangskommunikations-Datei 126 verwendet. Wenn die Abgangskommunikations-Datei 126 einmal neu gespeichert worden ist, endet dieser erste Stapelverarbeitungsjob. An dieser Stelle ist der zweite Stapelverarbeitungsjob bereit, zu beginnen.
In einem Schritt 1810 wird die Logdatei 122 im zweiten Stapelverarbeitungsjob erneut zu einer weiteren sequentiellen Datengruppe exportiert. In einem Schritt 1812 wird die Logdatei 122 mit einer importierten Datei erneut gespeichert. In einem Schritt 1814 endet der zweite Stapelverarbeitungsjob.
Die Neuorganisation im Schritt 1804 wird nun detaillierter beschrieben. Das Ziel dieser Neuorganisation besteht im Reinigen irgendwelcher Datensätze, die keine gültigen Tageszeitstempel haben, oder von Daten-Datensätzen, die keine entsprechenden Steuerdatensätze haben, und zum Löschen von abgelaufenen Datensätzen. Fig. 19 ist ein Flußdiagramm, das das Verfahren dieser Neuorganisation darstellt. Die Neuorganisation wird in zwei Phasen durchgeführt. Unter Bezugnahme auf die Fig. 1 und 19 wird nun die erste Phase dieses Programms beschrieben.
In einem Schritt 1902 wählt das ABAP-Programm alle Steuerdatensätze 148 der Logdatei 122 aus. Wenn das ABAP-Programm einen beendeten Datensatz findet, hält es den Datensatz für einen Tag und löscht ihn dann. Wenn ein Datensatz fehlerhaft beendet ist, wird er nach drei Tagen gelöscht. Der Dateityp des ausgewählten Datensatzes wird untersucht. Wenn der Dateityp der Master-Steuer-(PC)- Datensatz 154 ist, wird er übersprungen. Wenn der Datensatz irgendein anderer Typ ist, fährt der Prozeß mit einem Schritt 1904 fort.
Im Schritt 1904 wird der Erzeugungstag des Datensatzes für gültig erklärt. Wenn der Tag nicht gültig ist, wird der Datensatz gelöscht. Wenn das Datum gültig ist, wird die Differenz zwischen dem Erzeugungsdatum und dem aktuellen Datum berechnet. Wenn diese im Schritt 1904 berechnete Differenz beim Datum die Residenzzeit für den spezifischen Dateientyp überschreitet (Schritt 1905), wird der Datensatz in einem Schritt 1910 gelöscht. Zusätzlich wird im Schritt 1910 ein Löschzähler für jenen Dateientyp inkrementiert. Wenn die Datendifferenz die Residenzzeit nicht überschreitet (Schritt 1905), wird ein Zurückhaltezähler für jenen Dateientyp in einem Schritt 1906 inkrementiert. Dieser Prozeß erfolgt für alle Steuerdatensätze.
In einem Schritt 1908 wird dann, wenn der Datensatz nicht gelöscht wurde und er eine Nachricht großer Menge darstellt, seine Stapelverarbeitungsnummer an eine interne Tabelle zur Verwendung in der zweiten Phase der Neuorganisation angehängt. Dies beendet die Phase 1.
In der Phase Zwei der Neuorganisation werden Daten-Datensätze für Gruppen großer Mengen verarbeitet, und alle Datensätze mit großen Mengen an Daten ohne übereinstimmende Steuerdatensätze (die durch Einträge in der im Schritt 1908 angehängten internen Tabelle dargestellt sind) werden gelöscht. Weil abgelaufene Steuerdatensätze großer Menge in der ersten Phase gelöscht wurden und nicht im Schritt 1908 zur internen Tabelle hinzugefügt wurden, werden ihre Daten- Datensätze hier behandelt.
In einem Schritt 1912 wählt das ABAP-Programm Datensätze mit großen Mengen an Daten vom Typ "PZ" oder "PO" aus. In einem Schritt 1913 wird die Stapelverarbeitungsnummer jedes Datensatzes in der internen Tabelle geprüft. In einem Schritt 1914 werden dann, wenn die Stapelverarbeitungsnummer nicht in der internen Tabelle existiert, alle Datensätze großer Menge für jene Stapelverarbeitungsnummer gelöscht.
Wenn alle Datensätze großer Menge verarbeitet werden, wird in einem Schritt 1916 der Master-Steuerdatensatz 154 der Logdatei 122 gelesen. Das Erzeugungsdatum und Zeitfelder dieses PC-Steuerdatensatzes werden mit dem aktuellen Datum und mit Zeitinformationen einem Updaten unterzogen. Somit zeigen diese Felder, das Datum und die Zeit, zu der die Datei zuletzt neu organisiert wurde. In einem Schritt 1918 endet das ABAP-Prog ramm.

8. Anzeigefunktion

Das Schnittstellensystem gemäß der vorliegenden Erfindung ist mit einem Merkmal versehen, das zuläßt, daß die Datensätze 148, 136 an der Logdatei 122 zuranzeige ausgewählt werden, und zwar basierend auf einem Dateientyp, der Stapelverarbeitungsnummer, der seriellen Nummer, der Klienteninformationen oder der Zeit und des Datums eines Updates. Dieses Merkmal ist für den Betrieb des Schnittstellensystems 100 nicht erforderlich, ist aber äußerst wertvoll bei einer Störungssuche. Das primäre Programmierwerkzeug zum Überwachen des Schnittstellensystems 100 wird YSPO-Transaktion genannt und ist im Transaktionsverarbeitungssystem 180 implementiert.
Der Überwachungsprozeß folgt den meisten Konventionen des Transaktionsverarbeitungssystems 180. Er zeigt einen Listenbildschirm an und läßt zu, daß eine Auswahl einer Zeile einen detaillierten Bildschirm zeigt.
Ein erster Bildschirm, der auf ein Eintreten in den Überwachungsprozeß hin angezeigt wird, wird der primäre Auswählbildschirm genannt und ist in Fig. 21 gezeigt. Der primäre Auswahlbildschirm 2100 gibt ein Anzeigen der aktuellen Stunde vor, und von Informationen, die zu allen Steuerdatensätzen gehört. Ein Drücken der ENTER-Taste zeigt die allerletzte Aktivität. Wenn die aktuelle Zeit innerhalb der ersten zehn Minuten der Stunde ist, werden alle Datensätze ausgewählt, die seit der vorherigen halben Stunde einem Updaten unterzogen worden sind.
Zusätzlich gibt es eine Anzeige von Datensatzzahlen für PO- und PQ-Typ- Datensätze. Diese Anzeige zeigt die Anzahl von PO-Datensätzen für den Status 1, 2, 3, 4, 8 und 9 und für alle PQ-Datensätze. Dies ist wertvoll, weil das Ziel der Prozesse darin besteht, die Anzahl von PO-Datensätzen (die eine Arbeit darstellen, die verfügbar ist und beendet werden muß) auf einem Minimum zu halten. Die Zahl von PQ-Datensätzen zeigt die Arbeit, die wartet, aber noch nicht zur Verarbeitung verfügbar ist. Der Bildschirm zeigt einen Eintrag des Dateientyps der Stapelverarbeitungsnummer, der seriellen Nummer, des ABAP-Namens, der letzten Update- Zeit und der Klienteninformationen an und läßt ihn zu.
Die Vorgaben-Dateientypauswahl ist P*, was alle Steuerdatensätze anzeigt. Wenn diese Vorgabenauswahl aufgerufen wird, werden Datensätze mit großen Mengen an Daten und der Schnittstellensystem-Steuerdatensatz übersprungen und können nur durch eine spezifische Referenz ausgewählt werden.
Zusätzlich zu dieser Vorgabenauswahl kann irgendein einzelner Dateientyp ausgewählt werden, einschließlich von Typen großer Mengen an Daten (PZ und PO), und des Master-Steuerdatensatzes 154 (PC). Wenn ein Sternchen im ersten Zeichen einer Stapelverarbeitungsnummer verwendet wird, werden alle Datensätze ausgewählt, die die anderen Auswahlkriterien erfüllen. Der Anwender kann ebenso eine spezifische Stapelverarbeitung auswählen.
Ein Weglassen eines Wertes im Feld für die serielle Nummer wählt alle Datensätze aus, die die anderen Auswahlkriterien erfüllen. Wenn eine Nummer in diesem Feld eingegeben wird, werden nur jene Stapelverarbeitungen ausgewählt, die größer als oder gleich der Nummer bzw. Anzahl sind.
Das ABAP-Feid stellt das spezifische Datenformat dar. Wiederum wird ein Sternchen im ersten Zeichen dieses Felds alle Datensätze auswählen, die die anderen Auswahlkriterien erfüllen. Die einzige andere Option, die Auswählen eines spezifizierten Formats besteht, kann auch ausgewählt werden.
Die Logdatei 122 ist "Klienten"-unabhängig. Benutzer können einen "Klienten" im Transaktionsverarbeitungssystem bezüglich einer Geschäftseinheit definieren, wie beispielsweise einer separaten Firma oder einer Abteilung oder einer Verzweigung, etc. Jedoch überträgt das Schnittstellensystem 100 Trigger zu spezifischen Klienten, und es ist möglich, die Suche basierend auf einem Klienten einzuschränken. Ein im Klientenfeld eingegebenes Sternchen wird alle Klienten auswählen.
Wenn einmal Informationen in den primären Auswahlbildschirm 2100 eingegeben wird, was eine Auswahl anzeigt, zeigt ein Listenbildschirm die Ergebnisse dieser Auswahl. Fig. 20 ist ein Diagramm, das den Listenbildschirm gemäß der vorliegenden Erfindung darstellt.
Nun werden unter Bezugnahme auf Fig. 20 dieser Listenbildschirm 2000 und zugehörige Funktionen beschrieben. Nahe dem unteren Ende des Listenbildschirms 2000 sind die Zahlen 0001/0440.
Dies zeigt an, daß 440 Datensätze die Auswahikriterien erfüllten, und daß der Bildschirm mit dem Datensatz 1 startet. An dieser Stelle ist es für einen Benutzer möglich, einen ersten Wert anstelle von 0001 einzugeben und zu einer spezifischen Stelle in der Liste zu springen. Zusätzlich kann der Bildschirm durch Verwenden der normalen SAP-Funktionstasten durchsucht werden. Diese SAP- Funktionstasten, die einem Fachmann auf dem Gebiet vertraut sind, stimmen mit den allgemein akzeptierten Standards für einen gemeinsamen Benutzerzugriff (CUA) überein, wie er durch die OBM-Systemanwenderarchitekturspezifikation definiert sind, und sind PF21, PF22, PF23 und PF24.
Ein Anordnen des Cursors auf irgendeiner Linie und ein Drücken von PF2 zeigt zusätzliches Detail für jenen Datensatz. Gemäß der vorliegenden Erfindung ist es möglich, zeitlich nach hinten und nach vom durchzusuchen, zu Daten-Datensätzen für einen großen Steuerdatensatz zu springen und zu anderen Bildschirmen zu springen, die für einen SAP-Modus einer Verarbeitung spezifisch sind.
Als Beispiel wird ein Anordnen des Cursors auf der Linie 4 und ein Drücken von PF2 betrachtet, wovon das Ergebnis in Fig. 12 gezeigt ist. Fig. 12 stellt einen Detail-Anfangsblockbildschirm 1200 für einen spezifischen Steuerdatensatz dar. Zusätzlich zu Informationen, die im Detail-Anfangsblockbildschirm 1200 angezeigt werden, sind das ABAP, das das erste Status-Update und seine Version des Datums- und des Zeitstempels berichtete, ebenso gezeigt.
Wenn der Dateientyp-PC auf dem primären Auswahlbildschirm eingegeben wird, wird ein Bildschirm mit speziellem Format angezeigt, der Steuerdatensatz-PC- Bildschirm genannt wird. Fig. 13 stellt einen Steuerdatensatz-PC-Bildschirm 1300 gemäß der vorliegenden Erfindung dar. Gemäß Fig. 13 zeigen im obersten Abschnitt des Steuerdatensatz-PC-Bildschirms 1300 Zeitstempel das Datum und die Zeit der letzten Neuorganisation der Datei, die letzte Zeit, zu der das Hochfahren des Schnittstellensystems lief, und die letzte Zeit, zu der das Überwachungsprozeß-Modul lief.
Im mittleren Abschnitt des Steuerdatensatz-PC-Bildschirms 1300 werden alle Schalter und Zähler für das Schnittstellensystem angezeigt.
Im unteren Abschnitt des Steuerdatensatz-PC-Bildschirms 1300 werden Versionssteuerinformationen für die COBOL-Module dargestellt. Diese Informationen enthalten das Datum und die Zeit, zu der das Prozeßmodul kompiliert wurde, und die Anzahl von Malen, die es seit dem Hochfahren des CICS ausgeführt worden ist.

Claims

1. Mit einem Computer durchgeführtes Verfahren zur Schnittstellenbildung eines externen Prozesses mit einem Transaktionsverarbeitungssystem (180), das eine Eingangsnachricht (132) vom externen Prozeß in einem Computersystem (300, 302) empfangen und an ihr arbeiten kann, das eine Vielzahl miteinander verbundener Datenprozessoren (302) enthält, auf denen externe Prozesse laufen, wobei das Verfahren folgende Schritte aufweist:

(a) Empfangen der Eingangsnachricht (132) vom externen Prozeß;

(b) Erzeugen eines Steuer-Datensatzes (148), der die Eingangsnachricht anzeigt;

(c) Schreiben des Steuer-Datensatzes (148) zu einer Schnittstellensystem- Logdatei (122) zum Melden des Empfangs der Eingangsnachricht;

(d) Bestätigen des Empfangs der Eingangsnachricht (132) zum externen Prozeß, um anzuzeigen, daß die Eingangsnachricht empfangen und gemeldet worden ist;

(e) Abtasten der Schnittstellensystem-Logdatei (122) und Triggern des Transaktionsverarbeitungssystems (180) in Reaktion auf ein Erfassen des Steuer-Datensatzes (148); und

(f) Liefern von Daten von der Eingangsnachricht (132) zum Transaktionsverarbeitungssystem (180);

(g) Empfangen einer Verarbeitungsstatusnachricht (150) vom Transaktionsverarbeitungssystem (180), um einen Verarbeitungsstatus der Eingangsnachricht (132) im Transaktionsverarbeitungssystem anzuzeigen;

(h) Updaten der Schnittstellensystem-Logdatei (122) basierend auf der Verarbeitungsstatusnachricht (150);

(i) Lesen des Steuer-Datensatzes (148) in der Schnittstellensystem- Logdatei (122), um einen Verarbeitungsstatus der Eingangsnachricht zu bestimmen und um zu bestimmen, ob eine Ausgangsnachricht zu senden ist;

(j) Speichern eines abgehenden Steuer-Datensatzes (138) in einer Kommunikations-Logdatei (126) basierend auf dem Schritt (i); und

(k) Übertragen von entweder einer Ausgangsdatennachricht oder einer Ausgangsstatusnachricht zu einem durch den abgehenden Steuer- Datensatz (138) bestimmten Zielort.

2. Verfahren nach Anspruch 1, wobei der Schritt (a) folgende Schritte aufweist:

Initialisieren eines Eingangsempfangs-Untersystems (102);

Empfangen der Eingangsnachricht (132) im Eingangsempfangs- Untersystem (102);

für Gültig erklären und Initialisieren einer Eingangsnachrichten- Anfangsblockinformation; und

Updaten der Anfangsblockinformation in der Eingangsnachricht (132); wobei der Schritt (e) folgende Schritte aufweist:

Durchsuchen der Schnittstellensystem-Logdatei (122) nach aktiven Steuer-Datensätzen;

Erzeugen einer Triggernachricht (134), die anzeigt, daß die Eingangsnachricht (132) empfangen und der Schnittstellensystem-Logdatei (122) gemeldet worden ist, und die die Stelle des Steuer-Datensatzes (148) anzeigt, die auf ein Melden eines Empfangs der Eingangsnachricht (132) erzeugt wird; und

Senden der Triggernachricht zum Transaktionsverarbeitungssystem (180); und

wobei der Schritt (h) weiterhin folgende Schritte aufweist:

Bestimmen, ob die Verarbeitungsstatusnachricht (150) eine Erneuerung zu einem existierenden Steuer-Datensatz (148), einen neuen Steuer- Datensatz oder eine Erneuerung zu einem Master-Steuerdatensatz (154) enthält;

Schreiben des neuen Steuerdatensatzes als Steuerdatensatz in die Schnittstellensystem-Logdatei (122), wenn die Verarbeitungsstatusnachricht (150) der neue Steuerdatensatz ist;

Wiederauffinden und Updaten eines existierenden Steuerdatensatzes von der Schnittstellensystem-Logdatei (122), wenn die Verarbeitungsstatusnachricht (150) die Erneuerung zu einem existierenden Steuerdatensatz ist; und

Wiederauffinden und Updaten des Master-Steuerdatensatzes in der Schnittstellensystem-Logdatei (122), wenn die Verarbeitungsstatusnachricht die Erneuerung zu einem Master-Steuerdatensatz ist.

3. Verfahren nach Anspruch 1, das weiterhin folgende Schritte aufweist:

(l) Durchsuchen einer Transaktionsverarbeitungssystem-Logdatei (128) in einem Bereich, der durch eine vorherige Markierung für ein Ende der Datei und eine aktuelle Markierung flir ein Ende der Datei definiert ist, um einen Transaktions-Datensatz (158) entsprechend dem Steuerdatensatz zu finden; und

(m) Hinzufügen eines Übereinstimmungs-Datensatzes (152), der eine Adresse des Transaktions-Datensatzes (158) enthält, zu einer Übereinstimmungs-Datei (124).

4. Verfahren nach Anspruch 3, wobei der Schritt (1) folgende Schritte aufweist: Durchsuchen der Schnittstellensystem-Logdatei (122), um den Steuerdatensatz zu finden;

Durchsuchen der Übereinstimmungs-Datei (124), um den Übereinstimmungs-Datensatz (152) entsprechend dem Steuerdatensatz zu lokalisieren;

Ändern eines Schnittstellensystem-Statuscodes und eines Dateientyps des Steuerdatensatzes, um einen fertigen Steuerdatensatz zu erzeugen;

Ersetzen des Steuerdatensatzes durch den fertigen Steuerdatensatz; wobei der Schritt (j) den Schritt zum Schreiben des fertigen Steuerdatensatzes als abgehenden Steuerdatensatz (138) zur Kommunikations-Logdatei aufweist; und

wobei der Schritt (k) folgende Schritte aufweist:

Empfangen eines Ausgangsdaten-Datensatzes (832) und eines Ausgangssteuer-Datensatzes (834) vom Transaktionsverarbeitungssystem (180); Hinzufügen des empfangenen Ausgangssteuer-Datensatzes (834) zur Schnittstellensystem-Logdatei (122);

Ändern eines Schnittstellensystem-Statuscodes und eines Dateientyps des Ausgangssteuer-Datensatzes (834), um einen fertigen Ausgangssteuer- Datensatz zu erzeugen;

Schreiben des fertigen Ausgangssteuer-Datensatzes als abgehenden Steuerdatensatz (138) zu einer Logdatei (126) für eine abgehende Kommunikation;

Durchsuchen der Logdatei (126) für eine abgehende Kommunikation, um den abgehenden Steuerdatensatz (138) zu finden;

Bilden einer Kommunikationsverbindung mit einem durch den abgehenden Steuerdatensatz (138) adressierten Zielortknoten;

Senden des abgehenden Steuerdatensatzes (138) zum Zielortknoten; und

Senden des Ausgangsdaten-Datensatzes (832) zum Zielortknoten.

5. Verfahren nach Anspruch 1, wobei der Schritt (k) folgende Schritte aufweist:

Erzeugen eines abgehenden Steuerdatensatzes (138) und Speichern des abgehenden Steuerdatensatzes in einer Kommunikations-Logdatei (126);

Bestimmen, ob ein Zielortadressenfeld des abgehenden Steuerdatensatzes (138) eine direkte Adresse enthält;

Bilden einer Verbindung zu einem durch die Adresse bestimmten externen Prozeß;

Erzeugen einer Ausgangsnachricht basierend auf dem abgehenden Steuerdatensatz (138); und

Senden der Ausgangsnachricht zum externen Prozeß,

und wobei der Sendeschritt folgende Schritte aufweist: Versuchen, basierend auf einer ersten Zielortadresse, eine Verbindung mit einem ersten externen Knoten herzustellen, und dann, wenn dies nicht erfolgreich ist, versuchen, basierend auf einer zweiten Zielortadresse, eine Verbindung mit einem zweiten externen Knoten herzustellen.

6. Verfahren nach Anspruch 5, das weiterhin folgende Schritte aufweist: Erfassen, ob ein Übertragungsfehler aufgetreten ist;

erneutes Senden der Ausgangsnachricht, wenn der Übertragungsfehler aufgetreten ist;

Zählen einer Anzahl von Versuchen zum Senden der Ausgangsnachricht;

Löschen der Ausgangsnachricht, wenn die Anzahl von Versuchen eine Schwellengrenze überschreitet; und

Ändern eines Dateientyps des abgehenden Steuerdatensatzes (138), wenn die Anzahl von Versuchen eine Schwellengrenze überschreitet, um einen fertigen abgehenden Steuerdatensatz zu erzeugen.

7. Verfahren nach Anspruch 1, das weiterhin folgende Schritte aufweist:

Durchsuchen der Kommunikations-Logdatei (126) um den abgehenden Steuerdatensatz (138) zu suchen;

Prüfen eines Master-Steuerdatensatzes, um zu bestimmen, ob eine Anzahl von Kommunikationsaufgaben eine Schwelle überschritten hat, wenn der abgehende Steuerdatensatz gefunden wird;

Prüfen, ob ein Kommunikationsknoten, auf den durch den abgehenden Steuerdatensatz (138) gezeigt wird, verfügbar ist;

Beginnen eines Kommunikationsprozesses für den Kommunikationsknoten.

8. Computersystem (100) zur Schnittstellenbildung eines externen Prozesses mit einem Transaktionsverarbeitungssystem (180), das eine Eingangsnachricht (132) vom externen Prozeß in einem Computersystem (300, 302) empfangen und verarbeiten kann, das eine Vielzahl miteinander verbundener Datenprozessoren (302) enthält, auf denen externe Prozesse laufen, wobei das System folgendes aufweist:

(a) eine Logdatei (122) zum Speichern eines Steuerdatensatzes (148) und zum Liefern von Daten von der Eingangsnachricht (132) zum Transaktionsverarbeitungssystem (180);

(b) eine erste Einrichtung (102), die mit der Logdatei (122) gekoppelt ist, zum Empfangen der Eingangsnachricht (132) von einem externen Prozeß und zum Melden eines Empfangs davon zur Logdatei (122), und zum Senden einer Bestätigung zum externen Prozeß, die den Empfang der Eingangsnachricht (132) bestätigt;

(c) eine zweite Einrichtung (104), die mit der Logdatei (122) gekoppelt ist, zum Liefern einer Triggernachricht (134) zum Transaktionsverarbeitungssystem (180), um anzuzeigen, daß die Eingangsnachricht (132) durch die erste Einrichtung (102) empfangen und gemeldet worden ist;

(d) eine dritte Einrichtung (106, 108), die mit der Logdatei (122) gekoppelt ist, zum Bestimmen eines Verarbeitungsstatus der Eingangsnachricht (132) im Transaktionsverarbeitungssystem (180) und zum Erzeugen eines abgehenden Steuerdatensatzes (138) eine Funktion des Status; und

(e) eine vierte Einrichtung (114), die mit der dritten Einrichtung gekoppelt ist, zum Erzeugen einer Ausgangsnachricht (140) als Ergebnis des abgehenden Steuerdatensatzes (138) und zum Übertragen der Ausgangsnachricht (140) zu einem durch den abgehenden Steuerdatensatz (138) bestimmten Zielort.

9. System nach Anspruch 8, das weiterhin folgendes aufweist: eine zweite Logdatei (126), die mit der dritten Einrichtung (108) und mit der vierten Einrichtung (114) gekoppelt ist, zum Speichern des abgehenden Steuerdatensatzes (138); und eine fünfte Einrichtung (110) zum Durchsuchen der zweiten Logdatei (126), um den abgehenden Steuerdatensatz (138) zu suchen, und zum Beginnen einer Kommunikationsaufgabe als Ergebnis des abgehenden Steuerdatensatzes.

10. System nach Anspruch 8, das weiterhin folgendes aufweist: eine fünfte Einrichtung (112), die mit der zweiten und mit der dritten Einrichtung gekoppelt ist, zum Initiieren der zweiten (104) und der dritten Einrichtung (108) in zeitlich periodischen Intervallen; und eine Zeitgebertabelle für eine verstrichene Zeit, um Zeitinformation in bezug auf eine Erzeugung von zeitlichen Abtastungen zu speichern, um die zweite (104) und die dritte Einrichtung (108) zu initiieren.

11. Computersystem (100) nach Anspruch 8, das folgendes aufweist:

(a) die Logdatei als erste Logdatei (122); und

(b) eine zweite Logdatei (126);

(c) wobei die erste Einrichtung folgendes aufweist: ein Eingangsempfangs- Untersystem (102), das mit der ersten Logdatei (122) gekoppelt ist, und das zum Empfangen einer Eingangsnachricht (132) vom externen Prozeß betreibbar ist, um einem Steuerdatensatz (148) einen derartigen Empfang an der ersten Logdatei (122) zu melden, und um eine Bestätigung zum externen Prozeß zu senden, die den Empfang der Eingangsnachricht (132) bestätigt;

(d) wobei die zweite Einrichtung folgendes aufweist: ein Trigger- Untersystem (104), das mit der ersten Logdatei (122) gekoppelt ist, und das zum Durchsuchen der ersten Logdatei (122) betreibbar ist, um den Steuerdatensatz (148) zu suchen, und um eine Triggernachricht zu liefern, die anzeigt, daß eine Eingangsnachricht (132) empfangen worden ist;

(e) wobei die dritte Einrichtung folgendes aufweist: ein Status-Untersystem (106), das mit der ersten Logdatei (122) gekoppelt ist und das zum Auslesen einer Verarbeitungsstatusnachricht vom Transaktionsverarbeitungssystem betreibbar ist, und zum Updaten von Steuerdatensatz- Information über die erste Logdatei (122), und ein Bestätigungs- Untersystem (108), das mit der ersten Logdatei (122) und mit der zweiten Logdatei (126) gekoppelt ist und zum Bestimmen eines Verarbeitungsstatus der Eingangsnachricht (132) betreibbar ist, und zwar durch Lesen von Steuerdatensätzen (148), die durch das Status-Untersystem erneuert sind, und zum Liefern eines abgehenden Steuerdatensatzes (138) zur zweiten Logdatei (126) für Steuerdatensätze, die anzeigen, daß eine Bestätigung angefordert ist; und

(f) wobei die vierte Einrichtung folgendes aufweist: ein Kommunikations- Untersystem (114), das mit der zweiten Logdatei (126) gekoppelt ist, und das zum Auslesen des abgehenden Steuerdatensatzes (138) aus der zweiten Logdatei (126) betreibbar ist, das zum Erzeugen einer Ausgangsnachricht (140) von dem abgehenden Steuerdatensatz (138) betreibbar ist, und zum Senden der Ausgangsnachricht (140) zu einem durch den abgehenden Steuerdatensatz bestimmten externen Zielort.

12. System nach Anspruch 11, das weiterhin folgendes aufweist: eine Übereinstimmungs-Datei (125), die mit dem Bestätigungs-Untersystem (108) gekoppelt ist, zum Liefern eines Index zu Transaktions-Datensätzen im Transaktionsverarbeitungssystem (180);

ein Kommunikationsüberwachungs-Untersystem (110), das mit der zweiten Logdatei (126) gekoppelt ist, und das zum Durchsuchen der zweiten Logdatei (126) betreibbar ist, um den abgehenden Steuerdatensatz (138) zu suchen, um zu bestimmen, ob eine Kommunikationsaufgabe für jeden der abgehenden Steuerdatensätze existiert, und um eine Kommunikationsaufgabe zu beginnen, wo nicht bereits eine existiert; und

ein Überwachungs-Untersystem (112), das zum Liefern eines künstlichen Initiierungsereignisses zum Bestätigungs-Untersystem (108), zum Trigger- Untersystem (134) und zum Kommunikationsüberwachungs-Untersystem (110) betreibbar ist.

13. Verwendung des Systems nach einem der Ansprüche 8 bis 12 für das Verfahren nach einem der Ansprüche 1 bis 7.

14. Datenprozessor (300) für ein Computersystem (300, 302), mit einer Vielzahl von miteinander verbundenen Datenprozessoren (302), auf denen externe Prozesse laufen, wobei der Datenprozessor ein Schnittstellensystem (100) nach einem der Ansprüche 8 bis 12 aufweist.