DE69501211T2

DE69501211T2 - Nachrichtensystem

Info

Publication number: DE69501211T2
Application number: DE69501211T
Authority: DE
Inventors: Kenneth Bugbee
Original assignee: British Telecommunications PLC
Current assignee: British Telecommunications PLC
Priority date: 1994-04-21
Filing date: 1995-04-21
Publication date: 1998-04-02
Anticipated expiration: 2015-04-22
Also published as: JPH09512359A; AU2263695A; EP0756724B1; JP3628698B2; WO1995029439A1; US6289392B1; GB9407971D0; DE69501211D1; EP0756724A1

Description

Die vorliegende Erfindung bezieht sich auf ein Nachrichtensystem zum übertragen von Nachrichten zwischen aufrufenden Programmen und aufgerufenen Programmen und insbesondere auf ein Nachrichtensystem, bei dem alle Nachrichten innerhalb eines definierten Nachrichtenblocks und über eine Nachrichtenschnittstelle übertragen werden.
Große Computersysteme umfassen im allgemeinen eine Anzahl von Komponenten oder Programmen, die über Aufrufe miteinander wechselwirken. Die Unterteilung eines großen Computersystems in eine Zahl von Programmen ist aus mehreren Gründen vorteilhaft, z.B. wird dadurch eine Anzahl von Computerprogrammierern in die Lage versetzt, an dem System mit einem gewissen Grad an Unabhängigkeit zu arbeiten, es ist möglich, das Computersystem zu modifizieren oder einfach aufzurüsten, und es ist möglich, daß die Programme innerhalb des Systems wiederverwendet werden in anderen Computersystemen.
Die Schnittstelle zwischen verschiedenen Programmen innerhalb eines Computersystems müssen definiert werden, so daß ein aufrufendes Programm in der Lage ist, ein aufgerufenes Programm anzusprechen. Bei bekannten Computersystemen ist die Schnittstelle zwischen Programmen in dem Computercode sowohl bei den aufruf enden als auch bei den aufgerufenen Programmen eingebaut, so daß bei Änderung eines aufrufenden Programms innerhalb eines Computersystems die Notwendigkeit einer Änderung der Schnittstelle auch die Änderung aller anderen Programme, die das veränderte Programm aufrufen, erfolgen muß, um sie an die neuen Anforderungen der Schnittstelle anzupassen.
Ein System, das eine Schnittstelle zwischen Anwendungen und verschiedenen Computern in einem Computernetz schafft, ist in der europäischen Patentanmeldung EP-A-0 414 624 beschrieben.
Ein weiteres Problem ergibt sich, wenn z.B. aufgrund der Erweiterung des Computersystems ein Programm von der ursprünglichen physikalischen Hardware, z.B. einem Mainframe- Computer, auf ein anderes physikalisches System verschoben werden muß, so daß die Schnittstelle aufgerüstet werden muß, um dieses zu ermöglichen. Diese Aufrüstung muß bei allen aufrufenden Programmen, die noch auf dem ursprünglichen Mainframe-Computer verbleiben, durchgeführt werden, zusätzlich zu den Programmen, die verschoben werden auf das physikalisch außerhalb liegende System.
Erfindungsgemäß wird nach Anspruch 1 geschaffen:
Ein Nachrichtensystem zum Übertragen von Nachrichten zwischen aufrufenden Programmen und aufgerufenen Programmen, bei dem alle Nachrichten innerhalb eines definierten Nachrichtenblocks und über eine Nachrichtenschnittstelle ausgetauscht werden;
wobei die Nachrichtenschnittstelle eine Speichervorrichtung zum Abspeichern eines Identifizierers bei jedem aufgerufenen Programm und eine Programmschnittstelle umfaßt, der Nachrichtenblock einen Steuerblock mit einem festen Format und einen Datenbereich mit einem freien Format umfaßt, der Steuerblock einen ersten Abschnitt zum Übertragen von Datengruppenschlüsselworten und einen zweiten Abschnitt für das Übertragen von Eigenschaften von Dateneinheiten umfaßt und der erste Abschnitt unverändert bleibt, wenn ein Nachrichtenblock zwischen der Nachrichtenschnittstelle und einem aufgerufenen Programm oder einem aufrufenden Programm ausgetauscht wird, und der zweite Abschnitt je nach Bestimmungsort des Nachrichtenblocks verändert wird;
und im Betrieb die Nachrichtenschnittstelle
i) einen ersten Nachrichtenblock von einem aufrufenden Programm enthält, der einen Identifizierer enthält;
ii) den Identifizierer mit einem speziellen aufgerufenen Programm und einer speziellen Programmschnittstelle assoziiert; und
iii) einen Nachrichtenblock zu dem speziellen aufgerufenen Programm unter Verwendung der speziellen Programmschnittstelle sendet.
Ausführungsformen der vorliegenden Erfindung reduzieren durch Schaffung eines Zentrallagers von Programmschnittstellensegmenten den Umfang von Schnittstelleninformation, die in den Programmen selbst enthalten sein müssen. So wird z.B. ein aufrufendes Programm, bevor es direkt mit einem aufgerufenen Programm kommuniziert, einen Identifizierer innerhalb eines definierten Nachrichtenblocks an die Nachrichtenschnittstelle absenden. Die Nachrichtenschnittstelle wird dann z.B. sowohl den Ort als auch Schnittstellenanforderungen des aufgerufenen Programms bestimmen. Wenn dieses aufgerufene Programm auf derselben physikalischen Maschine lokalisiert ist, kann ein relativ einfaches Kommunikationsprotokoll verwendet werden. Wenn das gerufene Programm sich jedoch auf einem Computersystem außerhalb befindet, kann die Meldung von dem aufrufenden Programm geeignet verpackt und über ein geeignetes Kommunikationsprotokoll an das aufgerufene Programm auf dem entfernten System abgeschickt werden.
Ausführungsformen der vorliegenden Erfindung sind außerdem insbesondere geeignet für die Verwendung bei Datenverwaltungssystemen und sichern durch Anfügen einer Markierung bei jeder Datengruppe und Verwendung von Nachrichtenblock und Nachrichtenschnittstelle wie definiert einen hohen Grad von Modularität zwischen aufrufenden und aufgerufenen Programmen, was sich aus der folgenden Beschreibung ergibt.
Im folgenden werden Ausführungsformen der vorliegenden Erfindung als Beispiel mit Bezug auf die beigefügten Figuren beschrieben, bei denen:
Figur 1 ein schematisches Diagramm der Beziehung zwischen einem Nachrichtensystem gemäß einer Ausführungsform der vorliegenden Erfindung und weiterer Komponenten eines Datenverwaltungs systems ist;
Figur 2 ein schematisches Diagramm von Komponenten einer Ausführungsform der vorliegenden Erfindung ist;
Figur 3 ein schematisches Diagramm der Beziehung zwischen logischen Objekten, die durch eine Ausführungsform der vorliegenden Erfindung genutzt werden, ist;
Figur 4 ein schematisches Diagramm der logischen Beziehung zwischen Komponenten der Speichervorrichtung (ODICT) einer Ausführungsform der vorliegenden Erfindung ist;
Figur 5 ein schematisches Diagramm der logischen Beziehung zwischen Steuerblockstrukturen ist, die durch eine Ausführungsform der vorliegenden Erfindung genutzt werden, und
Figur 6 ein schematisches Diagramm eines Beispiels eines Aufrufs einer Kapsel durch eine Transaktion ist, wobei eine Ausführungsform des Nachrichtensystems nach der vorliegenden Erfindung verwendet wird.
Ausführungsformen der vorliegenden Erfindung ermöglichen es, daß Teile eines komplexen Computersystems, insbesondere bei einem Datenverwaltungssystem, verändert werden können, ohne daß Änderungen oder Zustimmungen von anderen Teilen erforderlich sind. Diese Flexibilität erlaubt es außerdem, daß Teile des Computersystems abgespalten werden und auf physikalisch separate Computer ausgelagert werden können.
Eine Ausführungsform der vorliegenden Erfindung, die innerhalb eines Datenverwaltungssystems verwendet wird, wird im folgenden beschrieben. Die Nachrichtenschnittstelle dieser Ausführungsform umfaßt eine Speichervorrichtung, die mit ODICT (Object Dictionary = Objektverzeichnis) bezeichnet wird, und eine Nachrichtenschnittstelle, die mit XCALL bezeichnet wird. Das Datenverwaltungssystem nach Figur 1 umfaßt eine Transaktionsverarbeitungsumgebung 1, die CICS (Handelsname von IBM) genannt wird, mehrere Transaktionen 2 (geschrieben in COBOL), ein Nachrichtensystem 3 nach einer Ausführungsform der vorliegenden Erfindung, mehrere Kapseln 4 und eine DB2/-Datenbank 5 (Handelsname von IBM). Somit sind bei dieser Ausführungsform die Transaktionsprogramme die aufrufenden Programme und die Kapselprogramme die aufgerufenen Programme. Wenn das Datenverwaltungssystem verwendet wird, so wird ein Aufruf nicht direkt von dem aufrufenden Programm (Transaktion 2) an das aufgerufene Programm (Kapsel 4) weitergeleitet. Der Aufruf wird zunächst an XCALL 3 und von da an das aufgerufene Programm, Kapsel 4, weitergeleitet. XCALL 3 leistet mehrere Dienste, wodurch im wesentlichen das aufgerufene Programm gegenüber dem aufrufenden und umgekehrt abgeschirmt wird.
In Figur 2 ist die Nachrichtenschnittstelle (XCALL) 3 außerhalb der aufgerufenen und der aufrufenden Programme in Speichervorrichtungen 6 definiert, die ODICT (Object Dictionary = Objektverzeichnis) genannt werden, und kodierte Versionen der Schnittstellendefinitionen werden in der Verarbeitungszeit verwendet, um zu identifizieren, welche Dateneinheiten zwischen den Programmen ausgetauscht werden. Wenn ein Programm kompiliert ist, werden die Definitionen für Aufrufe, die es macht und/oder von anderen Programmen erhält, von dem Verzeichnis kopiert.
Nur solche Komponenten, die notwendig sind zum Spezifizieren des Aufrufs, der kompiliert wird, werden in ein aufrufendes Programm kopiert. Die Komponenten, die für alle Aufrufe erforderlich sind, werden kopiert, wenn ein aufgerufenes Programm kompiliert wird.
Wenn das aufgerufene Programm geändert wird, um neue oder verbesserte Dienste für einige aufrufende Programme zu bieten, bedeutet die Abschirmungsfunktion von XCALL, daß andere aufrufende Programme nicht betroffen sind.
XCALL verschiebt als Daten ein Attribut zur Zeit von dem Datenbereich des aufrufenden Programms zu dem Datenbereich des aufgerufenen Programms und/oder zurück. XCALL verwendet kodierte Beschreibungen der Schnittstelle in Form von Datengruppennummern (oder Daten-Entity-Nummern), Spaltennummern und Spaltenlängen, die kopiert wurden aus ODICT, als die Programme kompiliert wurden. Dieser Prozeß läuft in derselben Art ab, wenn die zwei Programme sich beide auf demselben Computer befinden oder sie sich auf separaten Maschinen befinden.
Einige der hier verwendeten Ausdrücke werden im folgenden definiert:
KAPSEL: Die Basiseinheit von XCALL. Der Name leitet sich von dem Ausdruck Einkapselung ab, was in den Kreisen der objektorientierten Programmierung die Technik zum Abschirmen von Daten und Prozessen gegenüber der Außenwelt bedeutet. Eine Kapsel umfaßt alle Datendefinitionen und VERFAHREN für eine gegebene GRUPPE (oder ENTITY). Das Anwendungsprogramm ruft ein Verfahren auf, und dann verwendet XCALL LDS-Tabellen, die von ODICT konstruiert wurden, um den Verfahrensnamen der richtigen Kapsel zuzuordnen. Allgemein gibt es eine Kapsel pro Gruppe (oder Entity), obgleich einige Gruppen jeweils eine für das Wiederauffinden und eine für das Aktualisieren haben. Sehr selten wird eine Gruppe durch mehr als eine Kapsel aktualisiert. Der Aufruf ist (bei Laufzeit) dynamisch statt (beim Verbinden) statisch, so daß Änderungen am Code, den er enthält, ausgeführt werden können, ohne daß eine erneute Kompilierung oder ein erneutes Testen der ihn verwendenden Programme notwendig ist. Die zusammengehörige Anordnung von Code und Daten hilft außerdem bei dem Problem der Identifizierung und Einflußanalyse.
ABGELEITETES FELD: Ein Feld, das durch ein Verfahren geschaffen wird aber nicht direkt in der Datenbank gehalten wird. Das Verfahren kann einen Wert, z.B. einen Vertragsbeginn und ein Vertragsende, berechnen, wobei es nützlich wäre, ein Datum für das Vertragsende zurückzugeben. Eine Transaktion könnte ein solches Feld ohne Rücksicht darauf benutzen, wie es abgeleitet wurde. Ahnlich könnte es umgekehrt benutzt werden: Bei gegebenen Daten bezüglich Vertragsbeginn und -ende könnte ein Aktualisierungsverfahren das Ende berechnen. Andere Verwendungen beinhalten Status- Flags und Fehler-Flags für Listentypenverfahren unter Verwendung eines Array von Eingabefeldern: Beim Return wird ein gewisser Mechanismus benötigt, um festzulegen, ob Daten für jedes der Eingabefelder gefunden wurden.
GRUPPE (oder ENTITY): Ein identifizierbarer Typ in der Datenbank. Dieses könnte eine DB2-Tabelle sein oder ein (Handelsname von IBM) Aufnahmetyp, z.B. der ein Produkt darstellt, oder es könnte eine zusammengesetzte Struktur sein, z.B. eine Adressenaufnahme mit dazugehöriger Postleitzahl, Stadt, Durchgang, Ortsbeschreibungen usw., wobei eine solche Gruppe Daten aus einer Anzahl von DB2-Tabellen enthält. Der Name der Gruppe ist gewöhnlicherweise der DB2- Tabellenname (wenn geeignet), ist aber begrenzt auf 18 Zeichen. Jede Gruppe hat ein eindeutiges Identifizierungsschlüsselwort oder eine Gruppennummer und zusätzlich eine vier Zeichen lange Gruppenabkürzung.
GRUPPENBLOCK (oder ENTITY BLOCK): Der Datenbereich, der von dem Precompiler für eine Gruppe erzeugt wurde. Es gibt zwei Typen: der Gruppenblock, wie er von einem Verfahrensaufruf (Verfahrensaufrufgruppenblock) erzeugt wurde, der gerade solche Felder enthält, die als Eingabe und Ausgabe für das Verfahren und andere Verfahren erforderlich sind; und der volle Gruppenblock (Kapselgruppenblock), wie er durch die Kapsel erzeugt wurde, welcher alle Felder in der Gruppe enthält. Die Namen in dem Gruppenblock umfassen die Gruppenabkürzung aus dem ODICT, gefolgt von den DB2-Spaltennamen, wobei Unterstreichungen ersetzt werden durch Bindestriche und die zwei Teile, die durch einen Bindestrich getrennt sind. Im Fall eines Kapselgruppenblocks wird ein "I-" für Aufrufe in die Kapsel (einschließlich "interner" Verfahrensauf rufe) oder ein "C-" für Gruppen vorangestellt, die als Ergebnis von Verfahrensaufrufen in anderen Kapseln enthalten sind. Die Größe des Gruppenblocks kann bestimmt werden von dem COBOL-Kompilierungs-Listing mit dem MAP- Optionssatz.
VERFAHREN: Ein Prozeß, der durch ein Programm aufgerufen wird, um eine einzige Aktion mit einer Gruppe durchzuführen. Als DB2-Ausdruck hieße dies das Einfügen einer neuen Zeile in einer Tabelle oder eine existierende Zeile auszulesen, zu aktualisieren oder zu löschen (aber man beachte, daß ein Verfahren auch verwendet werden kann, um Datenbanken (Handelsname von IBM) bei anderen Datenspeichersystemen zu bearbeiten). Ein Verfahren wird im allgemeinen auf Parameter warten. Diese beinhalten EINGABE- und AUSGABE-Datenspezifikationen, welche die Gruppenfeldnamen (allgemein Datenbankspaltennamen) mit den aufrufenden Programmdatenfeldem (im Arbeitsspeicher oder beim Link) verbinden. Felder können als zwingend oder optional beschrieben werden (eher auf der Verfahrensebene als auf der Kapselebene). Andere Parameter beziehen sich auf die Anzahl von zurückgegebenen Gruppenanfragen, die Anzahl von Eingabedatenfeldern in einer zur Verfügung gestellten Tabelle und so weiter. Die Verfahren werden je nach Zweck und Verwendung benannt, insbesondere unter Verwendung eines Präfixes, um den Verarbeitungstyp zu kategorisieren (GET, INS, MOD, DEL etc.).
ODICT: Das Objektverzeichnis. Dies ist ein Satz von DB2- Tabellen, der Einzelheiten über Gruppen, Kapseln und Verfahren enthält. Gruppeninformation beinhaltet die Felder, die sie umfaßt, einschließlich abgeleiteter Felder. Genauso, wo sie eine Quelle für Informationen für Applikationsentwickler ist, dient ODICT auch dem Zugriff durch den Precompiler, um XCALL-Statements zu expandieren und die notwendigen Datenbereiche einzufügen. Bei der Verarbeitungszeit werden LDS-Tabellen, die hieraus erzeugt wurden, durch XCALL verwendet, um von dem erforderlichen Verfahren die geeignete Kapsel zum Aufruf abzuleiten.
PARTITIONEN: Logische Untersektionen der Datenbank, die die physikalische Verteilung über eine Vielzahl von Plattformen ermöglichen. Obgleich dies nicht speziell für XCALL-Datenbanken gilt, hat das Partitionieren einen Einfluß auf den Aufbau des Einlesens vom DB2-Join-Typ, wenn dies über Partitionsgrenzen hin erfolgt.
PRECOMPILER: Software, die XCALL- und XC-Statements, die Quellen enthalten, nimmt, in geeignete COBOL-CALL-Statements übersetzt und Datendefinitionen aus dem ODICT einbindet. Er muß an einer Stufe im Kompilierungsprozeß eingebunden werden.
SUPERKAPSEL: Der Gegensatz zur Basiskapsel ("normale" Kapsel). Wie der Name andeutet, ist dies eine Kapsel auf "höherer Ebene". Wenn Daten angefordert werden, die erhalten werden durch Zugriff auf mehr als eine Gruppe, z.B. bei einem DB2-Join-Typ, dann kann dies sehr effizient unter Verwendung einer Superkapsel durchgeführt werden. Typischerweise kann eine Superkapsel erforderlich sein für Bildschirmauflistungen, wo Spalten von unterschiedlichen Gruppen ausgelesen werden. Eine Superkapsel kann auch in Betracht kommen, wenn die Wiederverwendbarkeit ein Thema ist, z.B. Aufbau eines Schirm-Headers oder einer Datenbanknavigation über PARTITIONIERUNGEN.
TRANSAKTION: Ein Online-Prozeß, der hervorgerufen wird durch und wechselwirkt mit einem Nutzer, der geschäftliche Zwecke verfolgt.
VERSION: von Gruppen und Verfahren. Gruppen können ein Aufrüsten durch Hinzufügen von neuen DB-Spalten und Abwerfen von obsoleten DB-Spalten erforderlich machen oder durch Erhalten von Daten von anderen Tabellen. Ähnlich werden Prozeßanforderungen geändert. Die XCALL-Umgebung trägt der Tatsache Rechnung, daß Verfahren und Gruppen Versionsnummern haben. Bei jeder gegebenen Verfahrensversion werden die höchsten gültigen Gruppenversionsnummern, die damit assoziiert werden können, in dem ODICT gehalten. Bei einer Transaktion kann eine Verfahrensversionsnummer spezifiziert werden (der Default-Wert bedeutet das Aufrufen der neuesten Version beim Precompiling), und es wird auf die geeigneten Versionen der Gruppen zugegriffen.
XCIB: der XCALL-Schnittstellenblock. Dies ist die Vorrichtung zur Kommunikation zwischen den verschiedenen Komponenten von XCALL: Transaktionen, Module, XCALL selbst und Kapseln, welche letztendlich auf die Datenbank zugreifen.
Eine allgemeine Beschreibung der vorliegenden Ausführungsform auf der Funktionsebene wird zunächst gegeben, gefolgt von einer detaillierteren Beschreibung der Aspekte dieser Ausführungsform.

ODICT

ODICT ist eine Datenbank (IBM Db2), die Einzelheiten von den Daten enthält, die durch einen Satz von aufgerufenen Programmen verwaltet werden - bekannt als Kapseln. Die Kapseln ermöglichen eine Anzahl von Diensten - bekannt als Verfahren. ODICT enthält außerdem Details dieser Verfahren und der Daten, die durch sie erfordert werden und/oder von ihnen zur Verfügung gestellt werden.
Die Daten bestehen aus einer Anzahl von Gruppen, von denen jede ein oder mehrere Attribute haben - bekannt als Spalten. Eine Gruppe hat einen Namen und eine Zahl (für alle Zeit festgelegt, wenn die Gruppe gegenüber ODICT definiert wird). Eine Spalte hat einen Namen (eindeutig innerhalb ihrer Gruppe), einen Datentyp, eine Länge und eine Zahl (wieder für alle Zeit festgelegt, wenn die Einheit zu ODICT hinzugefügt wird).
Es ist von Vorteil, wenn eine Gruppe eine oder mehrere Db2- Tabellen und/oder (Handelsname von IBM) Datensätze hat, obgleich dies nicht notwendig ist.

Nachrichtenübertragung in XCALL

Im Zentrum der XCALL-Bearbeitungs-Architektur ist der definierte Nachrichtenblock, der von einem aufrufenden Programm an ein aufgerufenes Programm und zurückgeschickt wird. Dieser Nachrichtenblock besteht aus Steuerinformation in einem festen Formatsteuerblock, dem XCIB (XCALL-Schnittstellenblock) und einem optionalen Datenbereich mit freiem Format, dem IRB (Intermediate Reguest/Response Block = Zwischen-Frage/Antwort-Block).
Ein Teil des XCIB enthält eine Liste von Dateneinheiten, die von dem aufrufenden Programm abgeschickt werden, und eine Liste von Dateneinheiten, die es von dem aufrufenden Programm anfordert. Diese Listen werden ausgedrückt als "Gruppennummer" und "Spaltennummer". Diese Listen werden "Map1" genannt, und es gibt eine für den Eingang und eine für den Ausgang.
Ein anderer Teil des XCIB enthält Beschreibungen der Anordnung und Länge der Dateneinheiten in Map1, was als "Map2" bekannt ist. Es gibt zwei Formate für Map2, eine wird verwendet zwischen einem aufrufenden Programm und XCALL; das andere wird verwendet zwischen XCALL und dem aufgerufenen Programm.
Der XCIB hat zwei Abschnitte. Das "globale" XCIB wird verwendet durch das aufgerufene Programm, XCALL und das aufgerufene Programm. Das "lokale" XCIB hat einen Inhaltssatz, wenn ein Aufruf an XCALL weitergereicht wird oder wenn eine Antwort an den Aufrufenden zurückgegeben wird; und einen anderen Satz, wenn ein Aufruf weitergereicht wird von XCALL an das aufgerufene Programm oder eine Antwort von dem aufgerufenen Programm an XCALL zurückgegeben wird. Map2 ist Teil des lokalen XCIB.
Wenn Daten von einem aufrufenden Programm übergeben werden, werden sie von dem Datenbereich dieses Programms zu dem IRB verschoben. XCALL führt diese Funktion mit einer Spalte zur Zeit für die angegebene Zahl von Zeilen bei jedem Eintrag in die Eingabe-Map1 durch. Die Länge und der Ort der Dateneinheiten werden von Map2 erhalten. Der Ort wird ausgedrückt als Zahl von Bytes von dem Beginn einer Zeile bis zum Start der Spalte. Das lokale XCIB enthält die Adresse des ersten Bytes für jeden verwendeten Gruppenblock.
Wenn XCALL eine Anfrage erhält, prüft es, ob das angeforderte Verfahren existiert und für den Nutzer zur Verfügung steht. Gewisse Steuerinformation wird dem XCIB hinzugefügt, einschließlich der Identität des Programms (Kapsel), das das erforderte Verfahren enthält.
XCALL leitet den Aufruf an die Kapsel weiter. Der vom Precompiler erzeugte Code aktualisiert Map2 mit den Einzelheiten der Schnittstelle des laufenden Verfahrens und ruft dann eine XCALL-Service-Routine auf. Diese Routine erzeugt den Datenbereich für die Kapsel, verschiebt Daten von dem IRB in diesen Bereich und erzeugt Zeiger für die Gruppenblöcke in dem XCIB. Der Datenbereich der Kapsel ist bekannt als EBB (Entity Block Block = Gruppenblockblock) und enthält einen oder mehrere Gruppenblöcke.
Die Gruppenblöcke werden durch die Kapsel verwendet und können eine Antwort enthalten, die an den Aufrufenden zurückgegeben werden soll. Wenn XCALL die Steuerung von der Kapsel zurückerhält, wird XCIB überprüft, um zu sehen, ob irgendwelche Daten in dem EBE zu dem Aufrufenden zurückgegeben werden müssen. Wenn solche vorhanden sind, wird der vorige Map2-Prozeß umgedreht, wobei der Ausgang von Map2 verwendet wird, um den IRB zu überschreiben.
Um diese Daten an das aufrufende Programm zurückzugeben, speichert XCALL Map2 erneut, was ursprünglich durch den Aufrufenden ausgegeben wurde, und verschiebt die Dateneinheiten von dem IRB zu den Gruppenblöcken unter Verwendung von Map2 und dem Ausgang von Map1 des Aufrufenden.

Precompiler

Der Precompiler 7 in Figur 2 nimmt XCALL-Statements in einem Quellprogramm 8 und bildet Quell-Statements aus ihnen unter Verwendung des Inhalts von ODICT 6.
Bei einem aufrufenden Programm erzeugt dieser generierte Code Steuerinformation in dem XCIB, einschließlich sowohl Map1 als auch Map2, und ruft dann das XCALL-Arbeitszeitprogramm auf.
Bei einem aufgerufenen Programm (Kapsel) erzeugt der Precompiler 7 einen Code, der die Aufrufe von dem XCALL freigibt, Map2 erzeugt, eine XCALL-Service-Routine aufruft, um die Daten von dem Aufrufenden abschicken zu lassen und dann die Steuerung der Sektion der Kapsel zu übergeben, die für das spezifizierte Verfahren geeignet ist.
Der Precompiler bildet Definitionen für die Datenbereiche für die "Gruppen", die in dem Programm verwendet werden. Bei dem aufrufenden Programm enthalten die Definitionen nur solche Gruppen und Spalten, die speziell in den Aufrufen von diesem Programm verwendet werden. Bei einem aufgerufenen Programm enthalten die Definitionen alle Gruppen und Spalten, für die die Kapsel einsetzbar ist. In beiden Fällen erscheinen die Daten als eine Tabelle für jede Gruppe. Eine Tabelle besteht aus einem oder mehreren Auftritten einer Zeile oder einer oder mehreren Spalten. Diese Tabellen sind bekannt als "Gruppenblöcke".
Ein Aufruf spezifiziert nur den erforderlichen Dienst (d.h. den Namen des Verfahrens), nicht das Programm, das aufgerufen wird, oder das System, in dem es gefunden werden kann.

Versionsunabhängigkeit

Sowohl Gruppen als auch Verfahren haben eine Versionsnummer in dem ODICT. Ein Verfahren kann sich dadurch ändern, daß der Satz an Spalten, der von ihm gefordert und/oder von ihm erhältlich ist, wechseln kann. Ahnlich können eine oder mehrere Spalten hinzugefügt werden oder entfernt werden von einer Gruppe. In beiden Fällen würde eine Gruppe von solchen Änderungen eine neue Version schaffen.
Datentyp und -länge einer Spalte, wie identifiziert durch Gruppennummer und Spaltennummer, darf sich nie ändern. Wenn eine Spalte ihre Länge oder ihr Format ändert, muß sie mit einer neuen Spaltennummer versehen werden. Der Spaltenname für die ursprüngliche kann für die neue Spalte wiederverwendet werden, und ein neuer Name kann dem alten Format zugeordnet werden.
Zusammen mit den maßgeschneiderten Gruppenblöcken in aufrufenden Programmen reduziert dieses Merkmal die Kopplung von aufrufenden und aufgerufenen Programmen auf ein Minimum.
Die letzte "öffentliche" Version einer Verfahrensschnittstelle wird verwendet werden, wenn ein aufrufendes Programm kompiliert wird. Wenn eine Kapsel kompiliert wird, werden die XCALL-Statements, die das Verfahren definieren, und Gruppenversionskombinationen, die gültig sind, verwendet, um den Freigabecode zu bilden. Wenn eine Kapsel eine Anfrage für eine nicht unterstützte Gruppe oder ein nicht unterstütztes Verfahren erhält, so wird diese durch diesen erzeugten Code zurückgewiesen.
Wenn ein altes aufrufendes Programm erneut kompiliert wird, wird es die letzte öffentliche Version der Gruppen aufnehmen, die es verwendet. Wenn daher eine Spalte "POSTCODE" gewöhnlich 7 Zeichen, jetzt aber 8 Zeichen lang ist, so muß das Programm nicht verändert werden, um das letzte Datenformat zu verwenden, wenn es nächstes Mal kompiliert wird. Wenn es möglich ist, könnte die Kapsel die Anfrage nach der alten Spaltennummer zulassen und einen trunkierten 7-Zeichen-Postcode abgeben. Auf diese Art wäre die Notwendigkeit, sowohl das aufgerufene als auch das aufrufende Programm gleichzeitig zu ändern, umgangen.

Verteilung/Skalierbarkeit

Einer der Gründe für die Verwendung des IRB als Zwischenglied zwischen dem aufrufenden und dem aufgerufenen Programm ist es, daß dies ein passender Teil in der Struktur ist, in welchem eine Kommunikationsverbindung zwischen Systemen eingebaut werden kann.
Wenn eine Kapsel physikalisch von dem Programm getrennt ist, das sie aufruft, wird XCALL den globalen XCIB und den IRB zu einer anderen Instanz von XCALL auf dem entfernten System übergeben. Das entfernte XCALL übergibt Daten an und empfängt eine Antwort von der Kapsel in derselben Art wie oben unter Verwendung von Map2 etc. Der globale XCIB und IRB werden an das "Heimat"-XCALL zurückgegeben, welches die Antwort an den Aufrufenden auf genau dieselbe Art wie im lokalen Fall weitergibt.
Dieses bedeutet, daß aufrufende und aufgerufene Programme, die sich formal auf demselben physikalischen System befanden, separiert werden können, ohne Notwendigkeit sie in irgendeiner Weise ändern zu müssen.
Aspekte der vorliegenden Ausführungsform werden nun mit weiteren Einzelheiten beschrieben. Wie oben beschrieben umfaßt die vorliegende Ausführungsform eine Speichervorrichtung, ODICT 6, eine Nachrichtenschnittstelle, XCALL 3 und außerdem einen Precompiler 7, wie aus Figur 2 ersichtlich.

ODICT im Betrieb

Um XCALL zu unterstützen, wird ODICT in zwei Stufen verwendet. Zur Zeit der Kompilierung nimmt ein Precompiler die COBOL-Quelle mit eingebetteten XCALL-Statements und erweitert diese zu COBOL-AUFRUFEN unter Einschluß der geeigneten Datenfelder. Die Hauptdatenbereiche sind der XCALL-Schnittstellenblock (XCIB), der der Kommunikationsbereich für die eigene Verwendung von XCALL ist, und ein Gruppenblock, um Daten an und von jeder Gruppe zu übertragen, auf die durch die Applikation zugegriffen wird.
Es gibt zwei Typen von Gruppenblöcken: der volle Gruppenblock, wie er in Kapseln aufgerufen wird und eingebaut wird, wenn XC-COPY-Statements für Modulaufrufe verwendet werden; und den angepaßten Gruppenblock, der innerhalb einer Transaktion oder anderer codeausgebenden XCALL-Verfahrensstatements erzeugt wird. In diesem letzteren Fall werden nur solche Felder eingebaut, die in den Eingabe- und Ausgabeabschnitten spezifiziert sind, wodurch die Größe der Datenbereiche, die in der Verarbeitungszeit benotigt werden, reduziert werden. In dem Fall, daß mehrere Verfahren dieselbe Gruppe bearbeiten oder mehrere Aufrufe desselben Verfahrens mit unterschiedlichen Eingabe- und Ausgabeanforderungen erfolgen, erzeugt der Precompiler einen zusammengesetzten Gruppenblock mit allen angegebenen Feldern.
Um eine Verwechslung der zwei Typen von Gruppenblöcken zu vermeiden, wird der erste allgemein als Kapselgruppenblock oder vollständiger Gruppenblock bezeichnet, während der letztere gewöhnlich als Gruppenblock oder Verfahrensaufrufgruppenblock bezeichnet wird.
Der zweite XCALL-ODICT-Zugriff erfolgt am Beginn jeden Tages, wenn Informationen in bezug auf Kapseln, Verfahren und Gruppen extrahiert werden in lineare Datensätze. Diese werden verwendet bei der XCALL-Verarbeitungszeit, um ein letztendliches Festsetzen zwischen Verfahrensaufrufen und Kapseln zu bewirken. Es ist möglich, ODICT direkt zu verwenden, aber dadurch muß ein Leistungs-Overhead geduldet werden. Loslösen von ODICT von der Verwendung zur Verarbeitungszeit erlaubt außerdem genauere Steuerung der Implementierung von Aktualisierungen von ODICT.

ODICT-XCALL-Support-Struktur

Logische Objekte

ODICT beschreibt eine Zahl von logischen Objekten, wie sie von XCALL verwendet werden. Die Hauptobjekte sind Kapseln, Verfahren und Gruppen, die im folgenden im einzelnen beschrieben werden, wobei Bezug genommen wird auf Figur 3.

GRUPPE 9

Dies ist ein identifizierbarer Typ in einer Datenbank. Dies könnte eine DB2-Tabelle oder eine (Handelsname von IBM) Datensatztype sein, z.B. eine, die ein Produkt darstellt, oder sie könnte von zusammengesetzter Struktur sein, z.B. vom Typ eines Adressendatensatzes mit dazugehöriger Postleitzahl, Stadt, Durchgang, Ortseinzelheiten und so weiter, wobei eine solche Gruppe Daten von einer Zahl von DB2- Tabellen enthält. Jede Gruppe wird aus einer Zahl von Feldem (Spalten), die für gewöhnlich DB2-Spalten entsprechen, bestehen. Felder können als abgeleitet beschrieben werden, d.h. eher berechnet als als physikalische Daten gehalten.
ODICT beschreibt jede Gruppe, indem es sie durch ihre Gruppennummer identifiziert. Jede Gruppe hat einen Namen von bis zu 18 Zeichen, der verwendet wird, um einen Gruppenfeldnamen innerhalb der Anwendung zu erzeugen. Dies ist eine Abkürzung für Präfixspalten mit nicht eindeutigen Namen (dies wird auch verwendet bei der Herstellung von Verfahrensnamen, die diese Gruppe verarbeiten) und zwei weiteren Präfixen zum Auflösen von Namensübereinstimmungen.

VERFAHREN 10

Ein Verfahren wird durch ein CICS- oder Stapelverarbeitungsprogramm aufgerufen, um eine Funktion bezüglich einer Gruppe durchzuführen. Bei DB2 würde dies das Einsetzen einer neuen Zeile in einer Tabelle bedeuten, oder eine existierende Zeile zu lesen, zu aktualisieren oder zu löschen (aber man beachte, daß ein Verfahren ebenso verwendet werden kann, um (Handelsname von IBM) Datenbanken oder andere Datenspeichersysteme zu bearbeiten).
Ein aufrufendes Programm kommuniziert mit dem Verfahren durch Zurverfügungstellung von Parametern an den Verfahrensaufruf. Diese beinhalten EINGABE- und AUSGABE-Datenspezifikationen, die die Gruppenfeldnamen mit den Datenfeldem des aufrufenden Programms (im Arbeitsspeicher oder beim Linken) verbinden.
Andere Parameter beziehen sich auf die Zahl von zurückgegebenen Gruppenanforderungen, die Zahl von Eingabedatenfeldem in einer ausgegebenen Tabelle und so weiter.
Die Verfahren werden eindeutig identifiziert durch den Verfahrensnamen, ein Feld mit 30 Zeichen, welcher bei dem Verfahrensaufruf verwendet wird. Verfahren werden je nach Zweck und Verwendung benannt, insbesondere durch Verwendung eines Präfix (auch bekannt als Aktionstyp), um den Typ der Verarbeitung zu kategorisieren (GET, INS, MOD, DEL etc.).
Zu jedem Verfahren speichert ODICT den Kapselnamen, einen Verwendbarkeits-Indikator und Rückgabedateneinschränkungseinzelheiten.

KAPSEL 11

Eine Kapsel gruppiert für gewöhnlich Verfahren, die auf eine gegebene Gruppe zugreifen. Ein spezieller Kapseltyp, genannt Superkapsel, gruppiert Verfahren, die auf einen verwandten Satz von Gruppen zugreifen. Applikationsprogramme rufen ein Verfahren auf, und dann verwendet XCALL ODICT- Daten, um den Verfahrensnamen mit der geeigneten Kapsel zu assozueren.
Jede Kapsel hat einen Eintrag, der sie durch Kapselnamen identifiziert, ein Feld mit fünf Zeichen, bei dem die ersten zwei das assoziierte Applikationssystem angeben. Weitere Einzelheiten sind ein Verwendungsindikator und die Nutzer-Id.

TABELLE 12

ODICT speichert die Struktur von DB2-Tabellen mit Einträgen für jede Spalte jeder Tabelle ab. Jede Gruppe wird durch keine, eine oder mehrere DB2-Tabellen gestützt, und jede Tabelle kann eine oder mehrere Gruppen unterstützen.

SPALTE 13

ODICT hat einen Eintrag zu jeder Spalte jeder Gruppe, ob DB2 oder abgeleitet. Dieses beinhaltet gelöschte Spalten (Spaltennummern werden niemals wiederverwendet, obgleich ein Mechanismus zum Wiederverwenden von Spaltennamen existiert, wenn sich z.B. das Format geändert hat). Spalten werden identifiziert durch die Spaltennummer innerhalb der Gruppennummer, und Einzelheiten über Typ und Größe werden zusammen mit jeder Spalte gehalten.

Gruppenversionen

Gruppen können Nachbesserung erfordern durch Hinzufügen neuer DB-Spalten und Fallenlassen von überholten, indem Daten von anderen Tabellen erhalten werden oder andere Modifizierungen einer Spalte vorgenommen werden. Für jede Gruppe hält ODICT einen Eintrag für jede neue Version. Allgemein wird die neueste Version verwendet, aber ein Verfügungsindikator kann dafür sorgen, daß eine neue Version eingegeben wird und in einer Testumgebung verwendet wird, ohne Produktionsapplikationen zu stören.

Verfahrensversionen

Ahnlich ändern sich Prozeßanforderungen. Insbesondere wird bei Änderung der Schnittstelle zu einem Verfahren z.B. dadurch, daß ein Eingabedatenfeld erforderlich wird oder sich das Format anderweitig ändert, dann eine neue Verfahrensversion erforderlich. Bei einer gegebenen Verfahrensversion werden die höchsten zulässigen Gruppenversionsnummern, die damit assoziiert werden können, im ODICT gehalten. Bei einer Transaktion kann eine Verfahrensversionsnummer spezifiziert werden (der Default ist es, die neueste Version zum Zeitpunkt des Precompiling zu verwenden), und es wird auf die geeigneten Versionen der Gruppen zugegriffen.

DB2-Tabellen-Einzelheiten

Die DB2-Tabellen, die durch ODICT abgespeichert wurden, werden mit Bezug auf Figur 4 beschrieben. KAPSEL (OCAP) 11 Kapseltabelle: enthält eine Zeile pro Kapsel.

GRUPPE (OENT) 15

Eine Zeile für jede Version jeder Gruppe. (Man beachte, daß eine Gruppe sich auf mehr als eine DB2-Tabelle beziehen kann.) Ebenso indiziert bei Entity_Abbrev, Entity_version (verstärkt eindeutig) und Entity_Name, Entity_Version (verstärkt eindeutig)

VERFAHREN (OMTH) 16

Normalerweise eine Zeile pro ausgelieferter Verfahrensversion, obgleich ODICT-Synchronisation mehr einfügen kann.
Jedes Verfahren gehört zu einer Kapsel. Wenn einmal ein Verfahren zur Verfügung gestellt wurde, so muß eine neue Version für jede Änderung bei dem Verfahren erzeugt werden.
Ebenso indiziert bei Capsule_Name, Method_Name, Method_Version für die Relation mit der Kapseltabelle (OCAP).

GRUPPENSPALTE (OCOL) 17

Eine Zeile für jede Spalte, ob DB2 oder abgeleitet, momentan verwendet oder vorige Gruppenversion. Definiert die Attribute jeder Spalte.

DB2-TABELLE (OXTB) 18

Zeigt Gruppenimplementierung durch DB2-Tabellen. (Eine Gruppe kann implementiert werden durch mehr als eine DB2- Tabelle.) Ebenso indiziert auf Base_Capsule für die Beziehung zur Kapseltabelle (OCAP). Es kann natürlich keine Tabellen für eine gegebene Gruppe geben, z.B. für (Handelsname von IBM) Daten.

(ODRV) 19

Eine Zeile für jedes abgeleitete Feld (ein Feld, das nicht physikalisch in einer DB2-Tabelle existiert, welches aber entweder berechnet wird oder gehalten wird in irgendwelchen anderen DBMS, z.B. (Handelsname von IBM)). Diese Information hätte als Indikatorspalte bei OCOL gehalten werden können, aber man hielt es für nötig, mehr Information später zu halten. Jede Zeile hier wird eine äquivalente Zeile in GRUPPEN-SPALTE (OCOL) haben.

SCHNITTSTELLE (OINT) 20

Definiert den Schnittstellenblock für jede Verfahrensversion, d.h. die Spalten, die durch diese Version verwendet werden, und ob sie zwangsläufig für Eingabe erforderlich sind oder verfügbar sind für die Ausgabe. Dies ist die Mehrfach-auf-Mehrfach-Beziehung zwischen Gruppenspalte und Verfahrensversion. Ebenso indiziert auf Entity Number, Column_Number für die Beziehung mit der Gruppenspaltentabelle (OCOL). Method_Name, Method_Version wird verwendet für "Vielfach"-Ende der Beziehung mit der Verfahrenstabelle (OMTH).

DB2-TABELLENSPALTE (OSHD) 21

Listet Spalten in der laufenden Version von DB2-Tabellen auf.

ABBILDEN DER GRUPPENSPALTE AUF GRUPPE (OMAP)

Listet die Spalten nach Namen auf, unterstützt durch jede Version jeder Gruppe und implementiert so den Vielfach-auf- vielfach-Link zwischen Gruppe und Gruppenspalte. Hält einen vollständigen Satz von Zeilen für alle Spalten, definiert für die Verwendung mit der Gruppenversion, einschließlich Spalten, die nicht länger verwendet werden, aber von Aufrufen durch alte Verfahrensversionen benötigt werden. ENTITY_NUMBER und COLUMN_NUMBER zeigen auf OCOL-Zeile mit Einzelheiten der Spalte. LAST_ENT_VER_USED enthält ENTITY_VERSION der letzten Gruppenversion, die diese Spalte verwendet.
Diese Tabelle wird von dem XCALL-Precompiler verwendet, um den Gruppenblock für eine gegebene Gruppenversion aufzubauen. Sie gibt außerdem den Namen für die Spalte an, welche dann verwendet werden kann beim Aufbauen eines Feldnamens für die Verwendung in einer Anwendung.
Ebenso ist unter Entity_Number die Column_Number für die Beziehung mit der Entity-Column-Tabelle (OCOL) indiziert. Die Entity_Number, Entity_Version wird verwendet für das "Vielfach"-Ende der Beziehung mit der tabellierten Entity (OENT). KAPSEL-ENTITY (OXCE)

GRUPPEN-VERFAHREN (OXME)

Kreuzreferenzverfahrensversionen und Gruppenvers ionen.
NB-Primärindex ist unter Entity_Number, Entity_Version, Method_Name, Method_Version
Ebenso indiziert unter Method_Name, Method_Version, Entity_Number, Entity_Version.
Man beachte, daß Verfahren mehr als eine Gruppe verarbeiten können und außerdem Gruppen von mehr als einem Verfahren bearbeitet werden können.

XCALL-Laufzeitsystem

Die Operationen des XCALL-Laufzeitsystems können wie folgt zusammengefaßt werden:
Die Transaktion ruft ein Verfahren auf
XCALL "sammelt" IRB-Daten von Transaktions-Gruppen- Blöcken
XCALL greift auf den linearen Datensatz zu, um die aufzuruf ende Kapsel zu finden
IRB-Daten werden der Kapsel "angegeben"
die Kapsel verarbeitet den Aufruf
XCALL "sammelt" IRB-Daten von den Kapsel-Gruppen-Blöcken
XCALL gibt Daten an Transaktionsblöcke zurück.
Das XCALL-Laufzeitsystem wird im folgenden mit weiteren Einzelheiten beschrieben.

Rückwärtiges Ende

Die niedrigste Ebene in der XCALL-Laufzeit, verantwortlich für den Aufruf der ausgewählten Kapsel, hat die folgenden Funktionen:

Kapselaufruf

Ein "Ebene 2"-Aufruf, der auch als Kapsel-Kapsel-Aufruf bekannt ist. Wenn eine Kapsel ein Verfahren aufruft, das sich in einer anderen Kapsel befindet, so muß es Informationen in einem separaten XCIB erzeugen. Um Namensfehler zu vermeiden, wird dies XC2B genannt, und X2-Präfixe identifizieren Feldnamen eher korrekt als die XC-Präfixe beim normalen XCIB. Es ist ebenso notwendig, mehr Spurinformation abzuspeichern und weitere Aufrufe zu verfolgen.

Steuerung und Fortsetzung (C/C)

Die zweite Ebene der XCALL-Laufzeit hat die folgenden Funktionen:
Verfolgt die aufgerufenen Kapseln.
Speichert den Status des laufenden Aufrufs.
"Besitzt" DBMS-Fäden/Laufeinheiten.
Identifiziert das geeignete rückwärtige Ende für entfernte Kapseln.
Leitet Anfrage an rückwärtiges Ende.
Verwaltet explizite Übergabeanfragen - Absenden von Übergaben an entfernte XCALLs so weit notwendig.

Vorderes Ende

Die erste Ebene der XCALL-Laufzeit hat die folgenden Funktionen:

Entity Block Block

Dies ist der kollektive Name für Kapsel-Gruppen-Blöcke, die bei der Laufzeit zugeordnet sind. Ein Speicherbereich ist zugeordnet, um die größte Menge von Daten, die von dem Verfahrensaufruf innerhalb der Kapsel zurückerwartet werden, abzuspeichern, und seine Größe wird die Gesamtgröße aller Kapselgruppenblöcke, die durch diese Kapsel verwaltet werden, multipliziert mit der Zahl von Zeilenanfragen, haben.

IRB

Der Intermediate Request/Response-Block. Dies ist der Datenbereich, der an die und von der Kapsel übergeben wird. Er enthält die Eingabe- oder Ausgabedatenfelder, die zusammengehängt sind, um den Platzbedarf zu minimieren, d.h. ohne Berücksichtigung der Gruppenstruktur.

Lokaler Aufruf

Ein "traditioneller" Aufruf einer Kapsel im lokalen Knoten: XCALL kann die Kapsel direkt von der Verarbeitung am rückwärtigen Ende aufrufen.

Map 1, Map 2A und Map 2B

Datenbereiche, welche Einzelheiten der Abbildung von Eingangs- und Ausgangsdaten in der IRB enthalten.

Remote Call

Ein Aufruf einer entfernten Kapsel. Dieser erfordert eine komplexere Verarbeitung und Steuerung (ab Version 3.0).

Transaktionsaufruf

Ein Standardaufruf, bei dem XCIB-Felder zur Steuerung verwendet werden. Der Precompiler gibt den Aufruf an einen geeigneten Eingabepunkt ein. Er berechnet außerdem die IRB- Größe als den größeren Wert von (erforderliche Zeilen Ausgangszeilenlänge) oder (ausgegebene Eingangszeilen Eingangszeilenlänge). Der sich ergebende Wert geht in XC- IRB-SIZE. Map1- und Map2a-Daten werden zu der Zeit, zu der der Aufruf stattfindet, vorgesetzt.

XCCB

Steuer- und Fortführungsblock.

XCCT

XCALL-Kapsel-Tabelle. Diese wird von den LDS-Tabellen geladen und enthält Einzelheiten jeder Kapsel, einschließlich Kapsel-Status, Besitz und Ort.

XCIB

Der XCALL-Interface-Block. Dies ist die Kommunikationsvorrichtung zwischen verschiedenen XCALL-Laufzeitkomponenten und auf rufenden Prozessen. Er enthält Informationen wie über die Kapsel und das Verfahren, das aufgerufen werden soll, Spurinformationen, Adressen von Gruppenblöcken und Einzelheiten der Abbildung von IRB in Gruppenblöcke.

XCMT

XCALL-Verfahrenstabelle. Diese wird von LDS-Tabellen geladen, und bei der Laufzeit sucht XCALL sie mit dem Verfahrensnamen als Schlüssel ab, wodurch festgelegt wird, welche Kapsel ihn enthält. XCMT hält auch den Status und die Zeilen, die angefragt werden bzw. zurückgegeben werden im einzelnen für das Verfahren.

XCNT

XCALL-Knotentabelle. Diese wird von LDS-Tabellen geladen und enthält Einzelheiten über jeden Knoten.
Die Beziehung zwischen den Steuerblockstrukturen, die bei XCALL verwendet werden, ist in Figur 5 dargestellt.

XCALL-STRUKTUR

Eingabepunkte

Es gibt verschiedene Eingabepunkte für XCALL je nach der Umgebung, in welcher der Aufruf stattfindet. Es gibt die folgenden Permutationen: Transaktionsaufruf/Kapselaufruf (d.h. Kapsel-Kapsel); CICS-Vordergrund/CICS-Hintergrund/Stapel; Lokal/Entfernt.

Die drei Ebenen, vorderes Ende, Fortführung & Steuerung und rückwärtiges Ende

In jedem Fall werden die Eingabepunkte durch die drei Ebenen der Verarbeitung unterstützt: Vorderes Ende, Steuerung und Fortführung und rückwärtiges Ende, bevor die angefragte Kapsel tatsächlich aufgerufen wird.

Verarbeitung seitens des Aufrufenden

Vom Precompiler erzeugter Code lädt Map1- und Map2a-Daten, um Caller-Entity-Block-Daten auf dem IRB abzubilden, berechnet die Größe des IRB und speichert dies und Spurinformationen im XCIB. Bevor der Eingabepunkt aufgerufen wird, werden Eingabedaten zu den Caller-Entity-Block-Feldern transferiert.
Nach jedem Aufruf von XCALL muß die Anwendung den Rückgabecode prüfen und sich entsprechend verhalten. Nachdem die Steuerung zurückgegeben wurde, wird die Spurinformation aktualisiert und werden alle angeforderten Daten in die genannten Ausgabefelder gegeben.

Eingabepunkt

Die Hauptfunktion des Eingabepunktes ist es, die Adressen von Gruppenblöcken zu bekommen, die als Parameter zum ursprünglichen Aufruf weitergegeben wurden. Aufgrund der Zahl der übergebenen signifikanten Parameter werden in XCIB (XC- EM-ADDR) Eingaben an diese Adressen gesetzt. Zusätzlich findet eine Überprüfung von z.B. der Umgebung statt.

Vorderes Ende

Dieses empfängt Anfragen von Anwendungsprogrammen (und von entfernten Systemen im Namen einer entfernten Anwendung) Es fängt entsprechende Sicherheitsinformationen ein und hält eine Spur von den empfangenen Aufrufen aufrecht. Es ist ebenso verantwortlich für das Abbilden der IRB auf die Caller-Entity-Blöcke. Wenn XCALL aufgerufen wird, sammelt das vordere Ende abgespeicherte Daten von dem Betriebssystem durch Ausführung von GETMAIN für die IRB, entweder ein CICS GETMAIN oder ein Assembler-Äquivalent für den Stapel verwendend. Die Größe des erzielten Raumes wird dann in XC- CURRENT-IRBSIZE gehalten.
Bei einem nachfolgenden Aufruf wird XC-IRB-SIZE wieder durch den im Precompiler eingesetzten Code in dem aufrufenden Programm gesetzt. Das vordere Ende vergleicht dieses mit XC-CURRENT-IRB-SIZE. Wenn die momentane Größe größer als oder gleich der erforderten Größe ist, ist keine weitere Aktion notwendig, andernfalls wird der momentane Raum mit FREEMAIN freigegeben und ein neuer IRB mit GETMAIN wiederum geholt.
Verschiedene administrative und Sicherheitsaktionen werden nun durchgeführt:
Inkrementierung des XCIB-Spurzeigers und Bewegung der momentanen Anfrageinformation in die neue Spureingabe;
Setzen von dem XCIB-Aufruferknoten und Aufgabennummerfeldern;
Verwendung des XCMT, um zu überprüfen, daß der Verfahrensname gültig ist, Holen des Kapselnamens (unter Berücksichtigung einer möglichen Verwendung des Testnetzes) und Sicherstellen, daß die Kapsel (wenn es eine lokale ist) verfügbar für den Typ der Anfrage ist (wenn nicht der geeignete SWE-Code gesetzt ist und an den Aufruf enden zurückgegeben ist);
Holen des Knotens von dem XCCT und Setzen der Knoten-Id in dem XCIB;
Holen der Sicherheitsinformation (User-Id von Middleware) und Berechnen einer Prüfsumme zum Erzeugen eines Sicherheitsprüffeldes;
Erzeugen der ersten XCCB beim ersten Aufruf für eine Aufgabe.
Speichern von XCCB-Einzelheiten: Adressen von Laufzeittabellen etc. und so weit geeignet von Kapsel- Kapsel-Aufrufinformation.
Das vordere Ende speichert dann die Anfragedaten von dem Aufrufenden und legt sie in die IRB, indem die Assembler- Routine XC700UAS hierfür aufgerufen wird (siehe den nachfolgenden Abschnitt über Map1- und Map2-Verarbeitung für eine genaue Beschreibung). XCIB-Einzelheiten werden in XCCB abgespeichert.
Nach Aufrufen von Steuerung und Fortführung behandelt das vordere Ende die Kapsel-Kapsel-Aufruf-Verarbeitung, indem Einzelheiten in die geeigneten XCIB-Felder zurückkopiert werden.
Danach ruft es die Assembler-Routine XC703UAS auf, welche im wesentlichen XC700UAS in umgekehrter Reihenfolge ist, um Daten von dem zurückgegebenen aktualisierten IRB in die Caller-Entitiy-Blöcke zu übertragen. Wenn Übergabeverarbeitung erforderlich ist, so findet es hier statt, ansonsten wird die Steuerung zurück an den Eingabepunkt und dann zu dem Aufrufenden übergeben.

Steuerung und Fortführung

Diese behält Einzelheiten der Kapseln, die eine Anwendung aufruft. Sie verwendet XCCT, um Anfragen an die geeignete Kapsel zu übergeben. Sie ist verantwortlich für die Behandlung von Abgaben und Übergaben, die explizit vom Aufrufenden gewünscht werden, oder Abgaben, die bewirkt werden durch Fehlerverarbeitungsanforderungen.
Abgabe/Übergabe-Aufrufe beinhalten das Prüfen von dem DBMS- Typ gegenüber jeder Kapsel, sofern sie durch diese Transaktion aufgerufen wird, bevor die gewünschte Aktion stattfindet.
Wenn der Aufruf nicht ein Abgabe- oder Übergabeaufruf ist, dann fährt C&C fort und nimmt an, daß es sich um einen Verfahrensaufruf handelt.
Wenn die aufgerufene Kapsel nicht in dem XCCB ist, wird das XCCT verwendet, um das System zu lokalisieren, in dem sich die Kapsel befindet, und den Typ des rückwartigen Endes, das verwendet werden sollte, um mit dem entfernten System zu kommunizieren.
Aktualisierungszugriffe werden überprüft und dann die Aufrufstatistiken aktualisiert. Wenn Aufrufeinschränkungen nicht überschritten wurden, so übergibt C&C die Steuerung an das rückwärtige Ende.
Bei Rückkehr von dem rückwärtigen Ende überprüft C&C, daß XCIB nicht manipuliert wurde und aktualisiert XCCB-Statistiken für diese Kapsel. Wenn der Rückkehr-SWE-Code 8 oder höher ist, erfolgt eine Ausgabe.
Schließlich wird die Steuerung an das vordere Ende zurückgegeben.

Rückwärtiges Ende

Ruft die geeignete Kapsel auf, welche die stabile Version oder eine Arbeitskopie oder ein Rumpf sein kann (die beiden letzten beim Testen). Es speichert den lokalen Teil des XCIB in den sicheren Bereich in dem XCCB und übergibt die Steuerung an die Kapsel.
Bei Rückgabe wird überprüft, daß nichts verändert wurde und daß der zurückgegebene Zeilenwert in Ordnung ist. Vor dem erneuten Speichern des lokalen XCIB wird der IRB mit den an den Aufrufenden zurückzugebenden Daten aufgebaut unter Verwendung der Assembler-Routine XC702UAS (siehe Map1- und Map2-Verarbeitung unten).
Die Steuerung geht dann zurück an C&C.

Kapselverarbeitung

Der Precompiler erzeugt einen Code zum Abspeichern von Kapseleinzelheiten im XCIB und um zu überprüfen, daß das Verfahren gültig ist und daß die erforderlichen Meldungsdaten übergeben worden sind.
Sie fasert dann die vorgelegten IRE-Daten unter Verwendung der Assembler-Routine XC701UAS auf. Wenn es das erste Mal ist, daß diese Kapsel aufgerufen worden ist, so wird XC704TCS verwendet, um die Speicherung für den Entity- Block-Block zu bewirken. Dies besteht aus all den Kapsel- Gruppen-Blöcken, so oft auftretend wie notwendig (XC-ROWS- REQUESTED).
Nach dem Setzen der Kapsel-Gruppen-Block-Adressen in dem XCIB führt die Kapsel dann das angeforderte Verfahren durch, aktualisiert den XC-SWE-CODE und die XC-ROWS- RETURNED-Felder im XCIB, wonach die Steuerung an das rückwärtige Ende zurückgegeben wird.

MAP1- UND MAP2-VERARBEITUNG

Datenbereiche, die durch Map 1 und Map 2 verwaltet werden

Wie oben erwähnt werden Daten unter den verschiedenen Teilen von XCALL unter Verwendung von drei Bereichen (ausschließlich jeder anderen Quellen- oder Bestimmungsortdatenfelder) weitergegeben:
Der Caller-Entity-Block, welcher der maßgeschneiderte Block ist, der gerade solche Felder enthält, die von dem Aufrufenden bezeichnet werden. Dieser wird auf einer aufruf enden Basis aufgebaut: Ein Gruppenblock kann sehr wohl Felder enthalten, die vorhanden sind als Ergebnis von mehreren unterschiedlichen Aufrufen, die sich auf unterschiedliche Felder beziehen. Wenn zusätzlich Aufrufe angeben, daß Arrays erforderlich sind, dann wird die OCCURS-Bedingung das Maximum für die Gruppe sein, die vom Compiler gefunden wurde. Auf diese Art und Weise sind die Gruppenblöcke nicht größer als notwendig.
Der Kapsel-Gruppen-Block, welcher der Gesamtgruppenblock ist mit allen Feldern, ob Datenbank oder abgeleitet, definiert als nichtgelöscht für diese Version der Gruppe.
Der Intermediate-Request/Response-Block (IRB), wo Daten ein- und ausgepackt werden für jeden individuellen Aufruf.
Die Steuerung der verschiedenen erforderlichen Bewegungen erfolgt durch Abbildungstabellen, welche die Quellen- und Bestimmungsfelder identifizieren und lokalisieren. Es gibt drei solcher Abbildungen.
MAP 1 enthält Eintragungen, bei denen jeder Teil Eingangs- bzw. Ausgangsdaten identifiziert: Effektiv gibt es zwei Listen, eine für Eingabe und eine für Ausgabe. Der Precompiler erzeugt Gruppen- und Feld-Nummern für jedes Feld, das in einer INPUT- oder einer OUTPUT-Bedingung in einem speziellen XCALL-Aufruf genannt wird. Es gibt keine implizite Beziehung zwischen Eingangs- und Ausgangsspezifikationen: Es kann z.B. nur einen signifikanten Eingabeeintrag und viele Ausgabeeinträge geben. Ein Eintrag, der auf Null gesetzt ist, indiziert das Ende jeder Liste. Es gibt einen Map1-Eintrag für jede Spalte, auf die Bezug genommen wird in einem gegebenen Aufruf, d.h. in der Input- und Output-Bedingung. Jede Liste wird durch Nullen beendet. Es gibt keine Beziehung zwischen den Eingabe- und Ausgabeelementen bei jedem Auftreten: Es braucht z.B. nur einen signifikanten Eingangseintrag und mehrere Ausgangseinträge zu geben. Die Werte hierin (und im Map2-Format A) werden durch vom Precompiler erzeugten Code geladen.
MAP2-Version A verbindet die IRB-Daten mit dem Caller- Entity-Block. Es gibt eine Eins-zu-eins-Beziehung zwischen Einträgen in dieser Abbildung und solchen in Map 1. Wie in Map 1 hat jeder Eintrag einen Input- und einen Output-Teil. Keine spezielle Indizierung des Endes jeder Liste ist erforderlich: Dies kann leicht aus Map 1 abgeleitet werden. Die Einzelheiten werden geladen durch den Precompiler, und XCALL sichert die Werte, bevor die Steuerung an die Kapsel abgegeben wird, indem sie abgespeichert werden, wenn der IRB mit den zurückgegebenen Daten neu aufgebaut wurde.
MAP2-Version B teilt dieselben physikalischen Datenbereiche, wobei Werte geladen werden durch vom Precompiler erzeugten Code, der innerhalb der Kapsel ausgeführt wird. Während Map 2A sich auf den Caller-Entity-Block bezieht, verbindet Map 2B die IRB-Daten mit dem Kapsel- Gruppen-Block. So gibt es einen Eintrag für jedes Feld in der Gruppenversion, die nicht als gelöscht markiert ist. Map 1 wird noch benotigt: Datenbewegungen zwischen IRB und Kapsel-Gruppen-Block hängen von der Existenz einer signifikanten Gruppen/Feld-Nummerkombination auf Map 1 ab, wobei der äquivalente Eintrag in Map 2B getroffen werden muß.

Beispiel für MAP1/MAP2-Verarbeitung

In diesem Beispiel wird die Manipulation von Eingabe und Ausgabe bei einem einfachen Verfahrensaufruf demonstriert, der zwei Eingabeschlüssel empfängt und ausgibt und für jeden eine Zeile zurückerhält. Obgleich etwas vereinfacht, sollte ein genaues Studium der Daten in jeder Stufe die Einzelheiten der IRB/Entity-Block-Wechselwirkung aufdecken.
Die Gruppe - PARROT - hat die Attribute, die in der Tabelle unten gezeigt sind, und wird in dem Lexikon (ODICT) beschrieben. Der spezielle Verfahrensaufruf erfordert nur eine Untergruppe der verfügbaren Spalten: Die anderen dienen zur Darstellung.
Gruppen-Einzelheiten (aus ODICT)
Gruppen-Nummer 500 Version 1
Gruppen-Name PARROT
Gruppen-Abkürzung PARR
Spalteneinzelheiten NB-Typ, Char = Character, Smallint = small integer (binär im Bereich zwischen 1 und 32767) Kapseldarstellung der Daten (Entity-Block) Besteht aus einer Anzahl von Einträgen (Zeilen) für alle Attribute der Gruppe (Spalten)
(Gesamtlänge der Zeile: 44 Byte) Aufruferdarstellung der Daten (Entity-Block) Besteht aus einer Anzahl von Einträgen (Zeilen) von allen Attributen der Gruppe (Spalten)
(Gesamtlänge der Zeile: 26 Byte) Verarbeitungseinzelheiten Tabellen aktualisiert vor Ausführung des XCALL-Aufrufs: Map 1: Map 2A: Caller-Entity-Block (unter der Annahme, daß ws-Felder durch Programm erstellt wurden)

Verarbeitung

Vorderes Ende aufgerufen: XC700UAS aufgerufen, um Daten vom Verfahren EB zu IRB zu verschieben: Bilden einer Reihe aus allen Eingabefeldern in Map 1 (Verarbeitung stoppt, wenn ein mit Nullen gefülltes Feld erreicht wird) in dem IRB. Für Eingabe-Arrays erfolgt das Aufreihen auf einer Zeilefür-Zeile-Basis. Die in der Berechnung benutzten Felder sind der Offset und die Länge innerhalb des Caller-Entity- Blocks in Map 2A und die Adresse des Entity Blocks (ursprünglich weitergegeben als Parameter zu dem ursprünglichen Aufruf von XCALL) und die Länge der Gruppenblockzeile in XCIB). Der Offset zählt von dem Beginn der Zeile, der inkrementiert wird um die Zeilenlänge für die nachfolgenden Zeilen. IRB INRALT
IRB-Daten zum Aktualisieren des Kapsel-Gruppen-Blocks: Erfolgt durch XC701UAS, unter Verwendung von Map1- und Map2b- Einzelheiten enthält Map 1 die Gruppen- und Feld-Nummer der Eingabedaten. Von den Map2b-Daten ist es möglich, die Länge von jedem Eingabefeld zu bestimmen, wobei die Gruppen- und Feld-Nummer mit der von dem Map1-Eintrag in Übereinstimmung gebracht werden. Für denselben Map2B-Eintrag ist der Offset innerhalb des Gesamtgruppenblocks verfügbar. Die Adressen der Gesamtgruppenblöcke werden gesetzt nach Akquisition des Hauptspeichers.
Die Kapsel verrichtet ihre Arbeit und belegt den Entity- Block (unter der Annahme, daß alle Felder, die für die Ausgabe verfügbar sind, markiert sind: Dieser Verfahrensaufruf erfordert nur eine Untergruppe)
XCIB wird aktualisiert, um anzuzeigen, daß 2 Zeilen zurückzugeben sind (XC-ROWS-RETURNED ist auf 2 gesetzt).
IRB wird durch XC702UAS gefüllt: Map 1 sagt uns wiederum, welche Ausgabe-Gruppen/Feld-Kombinationen erforderlich sind, Map 2B wo sie sich in dem Kapsel-Gruppen-Block befinden:
Verfahren-Gruppen-Block aktualisiert durch XC703UAS unter Verwendung von Map 1 und Map 2A, bei denen die Werte abgespeichert wurden durch Verarbeitung des rückwärtigen Endes:
Die Verarbeitung durch die verschiedenen Applikations- und XCALL-Ebenen bei der Ausführung eines einzigen Aufrufs einer Kapsel werden nun mit Bezug auf Figur 6 beschrieben. Die vier Prozesse, bezeichnet mit 1, 2, 3 und 4 in Figur 6, werden zunächst beschrieben.

XC700UAS (Prozeß 1 in Figur 6) - BAUT IRB AUS ANWENDUNGSGRUPPEN-BLÖCKEN

Initialisieren des IRB-Headers.

Startverarbeitung bei dem ersten Eingabefeldeintrag in MAP1, fährt fort, bis eine Spaltenzahl Null gefunden wird oder ein Eintrag 255 verarbeitet wird. Führt den Prozeß einmal für jede Eingabezeile durch.
Berechnet den Ort, von dem aus verschoben werden soll, durch ...
a) Lesen der Adresse des Beginns des Gruppenblocks aus dem XCIB-Gruppeneinzelheitenarray-Eintrag, auf den durch den momentanen Map2a Eintrag gezeigt wird.
b) Subtrahiere 1 von der Zahl der momentanen Zeile, multipliziere sie mit der Länge einer Zeile (angegeben in dem Gruppeneinzelheitenarray) und addiere das Ergebnis zu der oben ausgelesenen Adresse.
c) Addiere zu dem Ergebnis die Zahl von Bytes in eine Zeile zum Start des Feldes (gehalten in dem momentanen Map2a-Eintrag).
Bewege die Zahl von Bytes, angegeben in der Feldlänge in dem momentanen Map2a-Eintrag von der Startadresse, die oben berechnet wurde, zur nächsten freien Position in dem IRB. Inkrementiere die nächste freie Position in dem IRB um die Zahl der bewegten Bytes.
Man beachte, daß der Map2a-Eintrag n dem Map1-Eintrag n entspricht.

XC701UAS (Prozeß 2 in Figur 6) - BAUT EBB-DATEN AUS IRB Initialisiere den EBB-Header.

Verarbeite jeden INPUT-Map1-Eintrag in der Reihenfolge, bis eine Gruppennummer von Nullen aufgefunden wird oder ein Eintrag 255 verarbeitet wird. Wiederhole den Prozeß so oft, wie es Eingabezeilen gibt.
Finde den Eintrag in Map2B, der der Gruppennummer und Spaltennummer für den laufenden Map1-INPUT-Eintrag entspricht. (Man beachte - beide haben ansteigende Spaltennummer innerhalb der Gruppennummerordnung.)
Berechne den Ort, wohin verschoben werden soll, durch ...
a) Lies die Adresse des Beginns des Gruppenblocks aus XCIB-Gruppeneinzelheitenarray-Eintrag, auf den durch den momentanen Map2b-Eintrag gezeigt wird.
b) Subtrahiere 1 von der Zahl der momentanen Zeile, multipliziere sie mit der Länge einer Zeile (angegeben in dem Gruppeneinzelheitenarray) und addiere das Ergebnis zu der oben ausgelesenen Adresse.
c) Addiere zu dem Ergebnis die Zahl von Bytes in eine Zeile zum Start des Feldes (gehalten in dem momentanen Map2b-Eintrag).
Verschiebe die Anzahl von Bytes, angegeben in der Feldlänge in dem laufenden Map2b-Eintrag von der nächsten Position, von der verschoben werden soll, in dem IRB zu der Startadresse, die oben in dem Kapselgruppenblock berechnet wurde. Inkrementiere die nächste Position, von der verschoben werden soll, in dem IRB um die Zahl der bewegten Bytes.

XC702UAS (Prozeß 3 in Figur 6) - BAUT IRB AUS KAPSELGRUPPENBLOCK/BLÖCKEN

Dieser führt dieselbe Verarbeitung wie XC701UAS durch, aber in umgekehrter Reihenfolge. Der Map1- und Map2b-Prozeß erzeugt die Adresse, von der verschoben werden soll, in den Kapselgruppenblöcken, und Daten werden in den IRB bewegt, wobei die Eingabedaten überschrieben werden.

XC703UAS (Prozeß 4 in Figur 6) - BAUT ANWENDUNGSGRUPPENBLÖCKE VON IRB.

Dieser führt die gleiche Verarbeitung wie XC700UAS durch, aber in umgekehrter Reihenfolge. Der Map1- und Map2a-Prozeß erzeugt die Adresse, an die verschoben werden soll, und Daten werden von dem IRB verschoben, wobei der existierende Inhalt der Anwendungsgruppenblöcke überschrieben wird.

Anwendung - "normaler" Code.

1. Die Anwendung legt die Eingabedaten, die an das Verfahren abgeschickt werden sollen, in die Variablen, die auf der rechten Seite des INPUT in dem XCALL-Statement genannt wurden.

Anwendung - vom Precompiler erzeugter Code

2. Aktualisiere Map 1 in XCIB mit Gruppen- und Spalten(Feld)-Nummern der Spalten, die auf der linken Seite des XCALL-Statements (Eingabe und Ausgabe) genannt wurden. Speichere Gruppeneinzelheiten in dem XCIB. Setze die Zahl der Eingabezeilen, die ausgegeben wurden, und die Zahl der Antwortzeilen, die angefordert wurden, in dem XCIB.
3. Aktualisiere Map2a mit dem Gruppen-Subscript, -Offset und -Länge der Spalten, die in Map1 genannt wurden. Aktualisiere XCIB mit der Größe von IRB, wie erforderlich für diesen Verfahrensaufruf.
4. Verschiebe Variablen, die auf der rechten Seite von INPUT in dem XCALL-Statement genannt wurden in die Gruppenblockvariablen, die Felder darstellen, die auf der linken Seite des XCALL-Statements genannt werden.
5. Aktualisiere XCIB mit den Einzelheiten des Programms, das den Aufruf macht.
6. Rufe das XCALL-Programm auf, das für diese Umgebung relevant ist, in welchem dieses Programm ausgeführt wird. Übergebe den XCIB, die erforderlichen Gruppenblöcke für INPUT- und OUTPUT-Felder.
XCALL - vorderes Ende
7. Aktualisiere lokalen XCIB mit Einzelheiten der übertragenen Gruppenblöcke.
8. Greife auf die Steuerspeichertabellen zu, die Verfahren, Kapseln, Knoten und Beziehung zwischen ihnen (wie in ODICT definiert) definieren. Stelle sicher, daß das Verfahren existiert und aktualisiere XCIB mit der Kapsel-Id für das Verfahren und die Knoten-Id für die Kapsel.
9. Wenn dies der erste Aufruf bei dieser "Aufgabe" ist, so sichere Speicherraum für den XCCB und aktualisiere den XCIB mit Einzelheiten vom aufrufenden Programm. Wenn es keinen IRB gibt oder der aktuelle zu klein ist, erlange Speicherraum für den IRB.
10. Rufe XC700UAS auf.
XCALL-XC700UAS
11. Verschiebe die Eingabedaten (wie in Map1 in dem globalen XCIB aufgelistet und beschrieben in Map2a in dem lokalen XCIB) von den Caller-Entity-Blöcken in den IRB.
12. Rückkehr zum vorderen Ende.
XCALL - vorderes Ende
13. Aufruffortsetzung und Steuerebene
XCALL - Fortsetzung & Steuerebene
14. Überprüfe, daß das aufrufende Programm Zugriff auf die Kapsel für die erforderliche Ebene hat (read only access etc.). Aktualisiere die Aufrufstatistiken in den Verfahrens- und Kapselsteuertabellen.
15. Aufruf des rückwärtigen Endes.
XCALL - rückwärtiges Ende
16. Sichere lokalen XCIB.
17. Aufruf des Kapselprogrammns
Kapsel - Precompiler-erzeugter Code (XC ENTRY- Statementerweiterung)
18. Prüfe, daß der Verfahrensname, die Verfahrensversion, Gruppennummern und Gruppenversionen, in diesem Aufruf übergeben wurden, gültig sind (wie definiert in ODICT und RECEIVE-Statements, wenn die Kapsel prekompiliert wurde).
19. Aufruf von XC701UAS.
XCALL - XC701UAS
20. Überprüfe, daß die laufende EBB-Größe ausreicht für den laufenden Aufruf. Wenn nicht, aktualisiere XCCB mit der erforderlichen EBB-Größe, setze den Rückgabecode und gib zurück an die Kapsel (d.h. fahre fort mit 23 unten).
21. Setze die Adressen der Gruppenblöcke innerhalb von EBB in dem lokalen XCIB.
22. Verschiebe die Eingabedaten (wie in Map 1 in dem globalen XCIB aufgelistet und beschrieben in Map2b in dem lokalen XCIB) in die Kapselgruppenblöcke von dem IRB.
23. Rückgabe an die Kapsel.
Kapsel - Precompiler-erzeugter Code (XC ENTRY- Statementerweiterung)
24. Überprüfe den Rückgabecode. Wenn EBB nicht groß genug war - Aufruf von XC704TCS, sonst Fortfahren mit 28 unten.
XCALL - XC704TCS
25. Wenn es einen existierenden EBB gibt, gib die Speicherung frei. Erreiche Speicherung für einen EBB der Größe, wie sie in XCCB angegeben ist.
26. Rückgabe an die Kapsel.
Kapsel - Precompiler-erzeugter Code (XC ENTRY- Statementerweiterung)
27. Aufruf von CX701UAS.
Fahre fort mit 20 oben.
Kapsel - Precompiler-erzeugter Code (XC ENTRY- Statementerweiterung)
28. Übergebe Steuerung an spezifizierten Verfahrenscode.
Kapsel - Verfahrenscode
29. Verarbeite die Eingabedaten in den Gruppenblöcken und erzeuge Antwort(Ausgabe)-Daten in den Gruppenblöcken. Aktualisiere den XCIB mit der Zahl der zurückgegebenen Zeilen.
30. Rückgabe zu XCALL
XCALL - rückwärtiges Ende
31. Wenn die Kapsel die Daten zurückgegeben hat - Aufruf von XC701UAS. Andernfalls fahre fort mit 34 unten.
XCALL - XC702UAS
32. Verschiebe die Ausgabedaten (wie in Map 1 in dem globalen XCIB aufgelistet und beschrieben in Map2b in dem lokalen XCIB) von den Kapselgruppenblöcken zum IRB.
33. Rückgabe zum rückwärtigen Ende.
XCALL - rückwärtiges Ende.
34. Speichere lokalen XCIB von der gesicherten Kopie, die oben bei 16 genommen wurde.
35. Rückgabe an Fortsetzung & Steuerung
XCALL - Fortführung & Steuerung
36. Aktualisiere die Antwortstatistiken in den Verfahrens- und Kapselsteuertabellen.
37. Rückgabe an vorderes Ende.
XCALL -vorderes Ende
38. Wenn die Kapsel Daten zurückgegeben hat - Aufruf von XC703UAS. Andernfalls fahre fort mit 41 unten.
XCALL - XC703UAS
39. Verschiebe die Ausgangsdaten (wie in Map 1 in dem globalen XCIB aufgelistet und beschrieben in Map2a in dem lokalen XCIB) zu den Caller-Entity-Blöcken von dem IRB.
40. Rückgabe an vorderes Ende.
XCALL - vorderes Ende
41. Rückgabe an Anwendung.
Anwendung - vom Precompiler erzeugter Code
42. Wenn die Kapsel Daten zurückgegeben hat - verschiebe die Ausgangsdaten von den Gruppenblöcken zu den Variablen, die auf der rechten Seite von INPUT in dem XCALL-Statement genannt wurden.
Anwendung - "normaler" Code
43. Prozeßantwort - mach weitere XCALLs etc.
Dieses Beispiel demonstriert, wie die Verwendung von dem XCALL-Nachrichtensystem Versionsunabhängigkeit zwischen Transaktion und Kapsel zuläßt. Die Transaktionssicht der Daten in Gruppe 1 und 2 ist die von Gruppe 1 mit den Variablen A bis D und Gruppe 2 mit den Variablen E und F. Die Sicht der Daten durch die Kapsel ist es, daß Gruppe 1 die Variablen A bis D, aber die Gruppe 2 die Variablen E bis G hat. Dieses kann z.B. dann auftreten, wenn eine zusätzliche Variable G der Datenbank hinzugefügt wurde (auf welche über die Kapsel zugegriffen wurde), wovon die Transaktion nichts bemerkt hat. Dies kann z.B. dann auftreten, wenn die Variable G der Datenbank hinzugefügt wurde, nachdem die Transaktion geschrieben worden ist. Unter Berücksichtigung dieser unterschiedlichen Sichten der Daten zwischen der Transaktion und der Kapsel, wenn XCALL nicht verwendet würde, d.h. wenn eine normale Verbindung zwischen Transaktion und Kapsel verwendet wurde, träte ein Problem auf, wenn auf Gruppe 2 zugegriffen würde. Wenn diese Gruppe gelesen wird, so würde, wenn E&sub2; erreicht wird, die Kapsel tatsächlich auf F&sub2; anstatt auf E&sub2; zugreifen, und auf E&sub2; anstatt auf G&sub1;. Somit würden unrichtige Daten an die Transaktion zurückgeleitet Wie oben beschrieben kann durch Verwendung von XCALL und einem intermediären IRB die Transaktion und die Kapsel jeweils ihre eigene Sicht derselben Gruppen haben und dennoch konsistent und korrekt auf diese Gruppen zugreifen durch Austausch ihrer Sichten der Daten über MAP2A und MAP2B mit XCALL.

REMOTE-CALL-VERARBEITUNG

Wenn die Steuer- und Fortsetzungsebene erfaßt, daß die Anfrage sich auf eine Kapsel auf einer entfernten Maschine bezieht anstelle auf das Aufrufen des rückwärtigen Standardendes, um den Kapselaufruf durchzuführen, wird in XCALL ein neues rückwärtiges Ende aufgerufen. Das neue rückwärtige Ende muß die Anfrage an das entfernte System weiterleiten.
Anstelle eines direkten Aufrufs einer Kapsel auf dem entfernten System wird das neue rückwärtige Ende ein neues XCALL-Serverprogramm auf dem entfernten System aufrufen. Dieses stellt außerdem statische Verbindungen zu drei Programmen her, dem vorderen Ende, der Steuer- und Fortsetzungsebene und dem rückwärtigen Ende. In diesem neuen Server ist nur das vordere Ende neu.
Wenn Steuerung von einem entfernten System erhalten wird, ist der XCIB alles, was zuerst erhalten wird (wenigstens von XCALL, wenn nicht vom ganzen System). Aufgrund der Kapseleinzelheiten, die lokal gehalten werden, ist Speicherplatz für die Anfrage- und Antwort-Blöcke und für das Aktualisieren des lokalen Abschnitts des XCIB nötig. Die folgenden Überprüfungen werden gemacht, bevor die Steuerung an die nächste Ebene übergeben wird.
i) Wenn es ein neuer lokaler Auftrag ist, sichere die aufrufende Auftragsnummer. Wenn nicht geprüft wird, daß der Job der gleiche ist.
ii) Überprüfe, daß die Kapsel lokal ist, und überprüfe vielleicht, daß ein Nachverfolgen über Schlüssel mit der lokalen Nachverfolgungstabelle übereinstimmt.
iii) Führe lokale Sicherheitsüberprüfung gegenüber dem entfernten System und der User-Id durch. Überprüfe, daß das Sicherheitsüberprüfungsfeld korrekt ist.
Wenn die Anfrage von einem entfernten System kam, ist es das vordere Ende, das den aktualisierten XCIB und den geeigneten IRE und Antwortblöcke zurück an das anfragende System sendet. Die RLEN-Felder in den Antwortblöcken werden angeben, ob und wieviel Daten für jeden von ihnen abgesendet werden sollten. Wenn alle geeigneten Daten abgesendet worden sind, wird der Speicherblock von den belegten Blökken befreit (außer wahrscheinlich von XCIB und XCCB), und es wird auf die nächste Anfrage gewartet.

Claims

1. Nachrichtensystem zum Übertragen von Nachrichten zwischen aufrufenden Programmen und aufgerufenen Programmen, bei dem alle Nachrichten innerhalb eines definierten Nachrichtenblocks und über eine Nachrichtenschnittstelle ausgetauscht werden;

wobei die Nachrichtenschnittstelle eine Speichervorrichtung zum Abspeichern eines Identifizierers bei jedem aufgerufenen Programm und eine Programmschnittstelle umfaßt, der Nachrichtenblock einen Steuerblock mit einem festen Format und einen Datenbereich mit einem freien Format umfaßt, der Steuerblock einen ersten Abschnitt zum Übertragen von Datengruppenschlüsselworten und einen zweiten Abschnitt für das Übertragen von Eigenschaften von Dateneinheiten umfaßt und der erste Abschnitt unverändert bleibt, wenn ein Nachrichtenblock zwischen der Nachrichtenschnittstelle und einem aufgeruf enen Programm oder einem aufrufenden Programm ausgetauscht wird, und der zweite Abschnitt je nach Bestimmungsort des Nachrichtenblocks verändert wird;

und im Betrieb die Nachrichtenschnittstelle

i) einen ersten Nachrichtenblock von einem aufrufenden Programm erhält, der einen Identifizierer enthält;

ii) den Identifizierer mit einem speziellen aufgerufenen Programm und einer speziellen Programmschnittstelle assoziiert; und

iii) einen Nachrichtenblock zu dem speziellen aufgerufenen Programm unter Verwendung der speziellen Programmschnittstelle sendet.

2. Nachrichtensystem nach Anspruch 1, bei dem jedes der aufgerufenen Programme mit einer Datengruppe assoziiert ist, wobei jede Datengruppe mehrere Dateneinheiten und ein eindeutiges Datengruppenschlüsselwort umfaßt und die Speichervorrichtung der Nachrichtenschnittstelle jedes Datengruppenschlüsselwort abspeichert.

3. Nachrichtensystem nach Anspruch 1 oder 2, bei dem die Eigenschaften der Dateneinheiten in dem zweiten Abschnitt des Steuerblocks den Ort und die Länge der Dateneinheiten umfassen und eine eindeutige Dateneinheitsmarkierung für jede Dateneinheit in dem ersten Abschnitt des Steuerblocks übertragen wird.

4. Nachrichtensystem nach einem der vorangehenden Ansprüche, bei dem die Dateneinheiten zwischen aufgerufenen und aufrufenden Programmen innerhalb des Datenbereichs des Nachrichtenblocks übertragen werden

5. Nachrichtensystem nach einem der vorangehenden Ansprüche, bei dem jeweils eine Dateneinheit zur Zeit von dem aufrufenden Programm und jeweils eine Dateneinheit zur Zeit an das aufgerufene Programm übertragen wird.