DE69623237T2

DE69623237T2 - Rechnergerät und Verfahren, um eine sequenzielle Vielzahl von Deltaströmen zusammenzufügen

Info

Publication number: DE69623237T2
Application number: DE69623237T
Authority: DE
Inventors: Mark Squibb
Original assignee: Deltatech Research Inc
Current assignee: Deltatech Research Inc
Priority date: 1995-11-14
Filing date: 1996-06-11
Publication date: 2002-12-19
Anticipated expiration: 2016-06-12
Also published as: JP4165912B2; DE69623237D1; EP0774720B1; EP0774720A3; US5745906A; EP0774720A2; JPH09190369A

Description

Diese Erfindung bezieht sich auf eine Computervorrichtung zum Zusammenfügen einer sequentiellen Mehrzahl von Deltaströmen, wobei jeder Deltastrom eine Änderung entweder zu einem vorherigen Deltastrom oder einem ursprünglichen Datenstrom darstellt. Im einzelnen bezieht sich die Erfindung auf ein Verfahren und eine Vorrichtung zum 1) Zusammenfügen einer sequentiellen Mehrzahl von Deltaströmen mit einem ursprünglichen Datenstrom, um einen aktualisierten Datenstrom zu erzeugen, 2) Zusammenfügen einer sequentiellen Mehrzahl von Deltaströmen, um einen kompilierten Deltastrom zu erzeugen, oder 3) Erzeugen eines negativen Deltastroms oder negativer Deltaströme, während ein oder mehrere Deltaströme mit einem ursprünglichen Deltastrom oder miteinander zusammengefügt werden. Das Verfahren und die Vorrichtung können in Verbindung mit einem Computersicherungsprozeß, Versionsverwalter oder dergleichen verwendet werden.
In der US-Patentanmeldung von Squibb, Seriennummer 08/039,702, die am 30. März 1993 eingereicht wurde, ist ein Verfahren und eine Vorrichtung zum Erzeugen einer Änderungsliste für eine ursprüngliche und eine aktualisierte Version einer Computerdatei offenbart. Das Verfahren und die Vorrichtung verwenden eine Hash-Generator-CPU, um einen Token-Satz für eine ursprüngliche Datei zu erzeugen. Eine Vergleicher-CPU verwendet später den Token-Satz und eine Fenstern-Technik, um die Positionen gleichzeitig existierender Seiten in der ursprünglichen und der aktualisierten Datei zu identifizieren und zu korrelieren. Die Vergleicher-CPU verwendet daraufhin die Informationen der gleichzeitig existierenden Seiten und den Rest der aktualisierten Datei (oder ursprünglichen), um ein Delta zu erzeugen, das die Unterschiede zwischen der ursprünglichen und der aktualisierten Datei ausdrückt. Das Delta wird an einen anderen Computer gesendet und mit einer Sicherungskopie der ursprünglichen Datei kombiniert, um eine Sicherungskopie der aktualisierten Datei zu erzeugen. Die ursprüngliche Datei und eine Reihe von Deltas werden verwendet, um historische Dateiinformationen auf kostenwirksame Weise zu bewahren.
Sicherungsoperationen, die das Zusammenfügen von Deltas erfordern, wie bei Squibb, sind deutlich stärker rationalisiert als diejenigen, die das Zusammenfügen inkrementaler Änderungen erfordern. Beispielsweise können gemischte Dateitypen von einem Gigabyte eine tägliche Änderung bei 0,5% ihrer Informationen aufweisen, jedoch können dieselben Änderungen durch 15% ihrer Dateien verbreitet sein. Eine tägliche Deltadatei, die unter Verwendung des Squibb- Verfahrens erzeugt wird, würde die 0,5%ige Änderung darstellen und eine Größe von ungefähr fünf Megabytes aufweisen, wohingegen eine Datei einer täglichen inkrementalen Änderung die 15%ige Änderung in Dateien darstellen würde und eine Größe von knapp über 150 Megabytes aufweisen würde. Wenn man eine wöchentliche vollständige Sicherung und tägliche inkrementale Sicherungen annimmt, werden 78 Gigabytes an Informationen in einem Jahr geschrieben, und jede inkrementale Sicherung dauert ungefähr drei Stunden. Unter Verwendung täglicher Deltasicherungen werden im Lauf eines Jahres lediglich 2 Gigabytes an Informationen geschrieben, und jede Sicherungssitzung dauert ungefähr fünf Minuten.
Die Zeit- und Raumeinsparungen sind in bezug auf eine 0,5%ige Änderung in einer Ein-Gigabyte-Datenbank sogar noch deutlicher. In einer Datenbank kann die 0,5%ige Änderung durch 100% der Datenbank verteilt sein, und Sicherungsoperationen, die eine tägliche Deltadatei, wie sie bei Squibb beschrieben wurde, verwenden, führen zu sogar noch beträchtlicheren Zeit-, Raum- und Kostenersparnissen.
Obwohl die Vorrichtung bzw. das Verfahren von Squibb einzigartige Vorteile besitzen, besteht ein Mangel darin, daß das Eins-Zu-Eins-Zusammenfügen von Deltas mit einer Sicherungskopie einer Datei eine beträchtliche Menge der CPU- Zeit eines Sicherungslagers (Backup-Lager) erfordert, besonders wenn erforderlich ist, daß das Sicherungslager von Tag zu Tag Deltas mit mehreren tausend Dateien zusammenfügt.
Obwohl die Anmeldung von Squibb offenbart, daß Deltadateien durch das Sicherungslager gesichert werden können, wäre es vorteilhaft, für jedes Delta auch ein negatives Delta zu schaffen und die negativen Deltas in dem Sicherungslager zu sichern. Das Speichern negativer Deltas würde es einem Sicherungslager ermöglichen, ein oder mehrere der negativen Deltas mit seiner aktuellen Sicherungskopie zusammenzufügen und dadurch eine frühere Version einer Datei zu rekonstruieren.
Da es beschwerlich sein kann, eine sehr große Anzahl von Deltadateien zu verwalten, wäre es wünschenswert, die Anzahl von Deltadateien (vor allem alte Deltadateien) periodisch zu verringern, wenn sie zu zahlreich werden. Ein bloßes Löschen jedes Nten Delta würde jedoch die notwendigen sequentiellen Beziehungen zwischen den Deltas zerstören.
Die Deltadateien (hiernach als "Deltaströme" bezeichnet), die in der früheren US-Patentanmeldung von Squibb erörtert werden, weisen Informationen auf, die die übereinstimmenden und veränderten Segmente zwischen 1) einem ursprünglichen Datenstrom (z. B. einer Computerdatei) und einem aktualisierten Datenstrom (z. B. einer revidierten Kopie der Computerdatei) oder 2) zwei aufeinanderfolgenden Aktualisierungen eines Datenstroms benennen. Strom bezieht sich auf die Tatsache, daß Daten eine sequentielle Beziehung aufweisen. Nicht alle Deltadateien (Änderungsdateien) weisen eine sequentielle Beziehung auf.
Es ist vorzuziehen, sequentielle Dateien auf einem sequentiellen Medium zu speichern, sowohl zur Erleichterung des Zugriffs, als auch weil sequentielle Medien bedeutend kostengünstiger sind als nichtsequentielle (suchfähige) Medien. Ein Beispiel eines sequentiellen Mediums ist das Magnetband, während Beispiele suchfähiger Medien Floppy- Disks, Festplattenlaufwerke und CD-ROMs umfassen.
Bis zum heutigen Zeitpunkt wurden kein Verfahren und keine Vorrichtung zum Erreichen der obengenannten Ziele entwickelt.
Ein existierendes Verfahren zum Zusammenfügen von Deltadateien ist das Iterativbauverfahren. Ein Iterativbausystem fügt eine Basisdatei nacheinander mit einer oder mehreren Deltadateien zusammen. Deltadateien können nicht gleichzeitig mit einer Basisdatei zusammengefügt werden. Das Iterativbauverfahren verringert nicht die Eingabe-/Ausgabe- Operationen (I/O-Operationen) der CPU, die das Zusammenfügen durchführt. Eine Basisdatei muß für jede Deltadatei, mit der sie zusammengefügt wird, einmal gelesen und geschrieben werden. Somit ist die Anzahl von I/O-Operationen, um N Deltadateien mit einer Basisdatei zusammenzufügen, gleich:
((N*2) + 1)* (Anzahl von Bytes in der Basisdatei)
Iterativbausysteme arbeiten lediglich mit suchfähigen Medien und wurden deshalb bisher nicht für ein Zusammenfügen von Deltaströmen, die auf einem sequentiellen Medium gespeichert sind, verwendet. Wenn ein Iterativbausystem verwendet würde, um auf einem sequentiellen Medium gespeicherte Deltaströme zusammenzufügen, müßten die Deltaströme zunächst in ein suchfähiges Medium kopiert werden, wodurch die Anzahl von I/O-Operationen, die durch eine CPU durchgeführt werden, weiter erhöht würde. Ein System zum Erzeugen negativer Deltadateien unter Verwendung eines Iterativbausystems ist nicht bekannt.
Eine Variation des Iterativbauverfahrens ist das Iterativbau-Pipelineverfahren. Eine Basisdatei wird einem Aktualisierungsprozeß, der einer einzelnen Deltadatei zugeordnet ist, zugeführt. Die Ausgabe des Aktualisierungsprozesses wird einem anderen Aktualisierungsprozeß zugeleitet, usw., bis eine abschließende aktualisierte Datei erzeugt wird. Das Iterativbau-Pipelinesystem wurde durch das Aufkommen von Multitasking-Systemen ermöglicht und funktioniert nur auf einem Multitasking-System. Ein Vorteil des Systems besteht darin, daß I/O verringert ist. Die Anzahl von I/O- Operationen, um N Änderungsdateien mit einer Basisdatei zusammenzufügen, ist gleich:
2* (Anzahl von Bytes in der Basisdatei)
Es bleiben jedoch mehrere Nachteile bestehen. Zunächst verursacht ein Leiten jedesmal, wenn ein Leitungspuffer voll ist, eine kontextabhängige Programmumschaltung. Für eine große Basisdatei, die mit zahlreichen Deltadateien (möglicherweise ebenfalls groß) zusammengefügt wird, treten viele kontextabhängige Umschaltungen auf, und die Leistungsfähigkeit des Systems leidet. Zweitens funktioniert das Iterativbau-Pipelinesystem lediglich in einer Multitasking- Umgebung. Drittens unterstützt das Verfahren nicht die Erzeugung negativer Deltadateien. Schließlich erfordert das Verfahren wiederum, daß Deltadateien in einem suchfähigen Medium gespeichert werden.
Ein letztes Verfahren zum Zusammenfügen von Deltadateien ist in der an Foster u. a. erteilten US-Patentschrift Nr. 5,278,979 offenbart. Foster u. a. offenbaren ein Versionsverwaltungssystem unter Verwendung von Zeigern. Wiederum müssen Dateien, die zusammenzufügen sind, in ein suchfähiges (nichtsequentielles) Medium kopiert werden, damit die Zeiger funktionieren. Die Patentschrift offenbart eine Fähigkeit, frühere Versionen durch einen Rückwärtsvergleich von Versionen wiederzuerlangen. Dies unterscheidet sich stark von der Erzeugung eines entgegengesetzten Wegs während eines vorwärtsgerichteten Zusammenfügens (alles in einem einzigen Durchgang). Weitere Nachteile des Foster- Verfahrens umfassen 1) eine geringe Leistungsfähigkeit bei sehr langen Basis- und Deltadateien (das Verfahren ist darauf ausgerichtet, "mehrere Versionen von Programmquellendaten zu speichern", wobei die Versionen in der Regel weniger als ein Megabyte an Daten beinhalten), und 2) eine kontextabhängige Begrenzung eines Verarbeitens von Änderungen von "Linien" (Daten müssen kontextabhängigen Regeln gehorchen und werden nicht als kontinuierlicher Strom behandelt).
Die WO A 94/23377 A bezieht sich auf Techniken zum Darstellen von Dateiunterschieden, die bei einem Computerdatei- Schutzsystem und anderen Systemen nützlich sind, und im einzelnen auf Dateiübertragungstechniken, die bei einem elektronischen Datensicherungssystem nützlich sind, bei dem lediglich Änderungen in einer Datei periodisch an das Sicherungssystem gesandt werden. Ein erstes Programm ist dazu ausgelegt, eine TOKEN-Tabelle mathematischer Darstellungen von Segmenten der Datei, wie sie zum Beginn einer Periode existiert, zu erzeugen. Ein zweites Programm wird am Ende der Periode verwendet, um eine ÜBEREINSTIMMUNG-Tabelle zu erzeugen, die die Position von Segmenten in der gegenwärtigen Datei darlegt, die identisch zu denen in der früheren Datei sind. Ein drittes Programm erzeugt eine ÜBERGANG- Tabelle, die wiedergibt, was sich in der aktuellen Datei befindet, das sich nicht in der früheren Tabelle befand, und wo es sich befindet.
Es ist die Aufgabe der vorliegenden Erfindung, ein System zu schaffen, das die Anzahl von Operationen, die durch die CPU eines Sicherungslagers durchgeführt werden, verringert.
Diese Aufgabe wird durch ein Verfahren gemäß Anspruch 1, Anspruch 4 und Anspruch 5, durch einen Computer gemäß Anspruch 7 und Anspruch 8 sowie durch ein physisches Speichermedium gemäß Anspruch 9 und Anspruch 10 gelöst.
Gemäß der vorliegenden Erfindung ermöglicht das System die Erzeugung negativer Deltas, wodurch die Wiedererlangung früherer Dateiversionen ermöglicht wird.
Überdies ermöglicht das System das Zusammenfügen mehrerer Deltas, um ein kompiliertes Delta zu erzeugen, wodurch die Verwaltungsanforderungen, die an die CPU eines Sicherungslagers gestellt werden, verringert sind.
Zudem überwindet die vorliegende Erfindung die Nachteile bekannter Delta-Zusammenfügungs-, Sicherungs- und Versionsverwaltungssysteme.
Die Erfinder haben eine Computervorrichtung und ein Computerverfahren zum Zusammenfügen einer sequentiellen Mehrzahl von Deltaströmen ersonnen. Das Verfahren und die Vorrichtung können verwendet werden, um 1) eine sequentielle Mehrzahl von Deltaströmen mit einem ursprünglichen Datenstrom zusammenzufügen, um einen aktualisierten Datenstrom zu erzeugen, 2) eine sequentielle Mehrzahl von Deltaströmen zusammenzufügen, um einen kompilierten Deltastrom zu erzeugen, oder 3) einen negativen Deltastrom oder negative Deltaströme zu erzeugen, wenn einer oder mehrere Deltaströme mit einem ursprünglichen Deltastrom oder miteinander zusammengefügt werden. Das Verfahren und die Vorrichtung können in Verbindung mit einem Computersicherungsvorgang, Versionsverwalter oder dergleichen verwendet werden.
Zusammenfassend baut ein Computer, um eine sequentielle Mehrzahl von Deltaströmen mit einem ursprünglichen Datenstrom zusammenzufügen, eine Kette von Transaktionselementen auf, die der sequentiellen Mehrzahl von Deltaströmen entsprechen. Das Transaktionselement mit der niedrigsten Nummer entspricht einem Deltastrom, der eine erste Revision des ursprünglichen Datenstroms darstellt, und sequentiell numerierte Transaktionselemente entsprechen sequentiellen Revisionen des ursprünglichen Datenstroms. Ein Verbraucherprozeß leitet eine Suchanforderung, in der Transaktionskette, nach einer Anzahl von Datenbytes ein, die an den aktualisierten Datenstrom zu übertragen sind. Die Suchanforderung wird mit dem hinteren Transaktionselement (demjenigen, das die letzte Revision des ursprünglichen Datenstromes darstellt) eingeleitet. Die Suchanforderung kann 1) mit Datenbytes erfüllt werden, die durch den mit der höchsten Nummer versehenen Deltastrom in der Transaktionskette, der in der Lage ist, Datenbytes zu liefern, bereitgestellt sind, oder 2) wenn die Transaktionskette nicht in der Lage ist, die Suchanforderung zu erfüllen, kann sie mit Datenbytes erfüllt werden, die durch den ursprünglichen Datenstrom bereitgestellt sind. Wenn eine Suchanforderung nicht erfüllt werden kann, ist der aktualisierte Datenstrom vollständig.
Optional kann eine Vorheriger-Strom-Position für jeden Deltastrom überwacht werden. Dies befähigt die Computervorrichtung, einen Datenrahmen, der aus Daten von einem oder mehreren vorherigen Strömen eines bestimmten Deltastromes besteht, an einen dem bestimmten Deltastrom zugeordneten negativen Deltastrom zu übertragen, wenn eine Quellenübereinstimmungsposition des bestimmten Deltastroms größer ist als die Vorheriger-Strom-Position des bestimmten Deltastroms. Eine Quellenübereinstimmungsposition wird jedem Übereinstimmungsrahmen eines Deltastroms zugeordnet und gibt an, wieviel eines vorherigen Stroms verbraucht sein hätte sollen, bis ein bestimmter Übereinstimmungsrahmen geladen wird. Wenn nicht genug eines vorherigen Stroms verbraucht wurde, ist dies auf eine Dateilöschung zurückzuführen, die zwischen aufeinanderfolgenden Deltaströmen auftritt; wobei die gelöschten Informationen in einem negativen Deltastrom aufgezeichnet werden. Nach der Übertragung eines Datenrahmens an einen negativen Deltastrom wird in dem negativen Deltastrom eine Übereinstimmungsrahmenumkehrung erzeugt.
Bei einer Abwandlung des Verfahrens beginnt man mit einem aktualisierten Datenstrom und fügt ihn mit einer sequentiellen Mehrzahl von negativen Deltaströmen zusammen, um einen gewünschten vorherigen Datenstrom (möglicherweise den ursprünglichen Datenstrom) zu erzeugen. Bei einer weiteren Abwandlung werden mehrere Deltaströme zusammengefügt, um einen kompilierten Deltastrom zu erzeugen.
Ein Vorteil des neu entwickelten Verfahrens und der neu entwickelten Vorrichtung ist eine Fähigkeit, Deltadateien (vorteilhafterweise durch Deltaströme dargestellt) mit einer Datei (ursprünglicher Datenstrom), die in einem sequentiellen Medium gespeichert ist, zusammenzufügen, ohne zunächst die Dateien an ein suchfähiges Medium übertragen zu müssen.
Weitere Vorteile umfassen 1) eine Fähigkeit, negative Deltaströme zu erzeugen, so daß frühere Versionen einer Datei rekonstruiert werden können, 2) eine Fähigkeit, in einem einzigen Durchgang eine Anzahl von Deltaströmen zusammenzufügen und negative Deltaströme zu erzeugen, wobei die Anzahl von durch eine CPU durchgeführten I/O-Operationen auf folgende beschränkt ist:
2* (Anzahl von Bytes in der Basisdatei),
3) eine Fähigkeit, mehrere Deltaströme zusammenzufügen, um einen kompilierten Deltastrom zu erzeugen, wobei die Verwaltungslasten, die einer CPU auferlegt sind, verringert werden, 4) eine Fähigkeit, in Computerumgebungen, die ein Multitasking nicht unterstützen, effizient zu arbeiten, und 5) eine Fähigkeit, das Zusammenfügen großer Daten- und Deltaströme effizient zu verwalten.
Während das offenbarte Verfahren und die offenbarte Vorrichtung spezifische Vorteile zur Verwendung bei sequentiellen Speichermedien liefern, sind sie auch zur Verwendung bei suchfähigen Medien effektiv.
Nach einer Prüfung der folgenden Beschreibung wird man erkennen, daß, da Deltaströme bezüglich einer ganzen Datei klein sind (ungefähr 0,5% der Gesamtgröße einer Datei), mehrere Deltas zusätzlich dazu, daß sie in einem zentralen Lager aufbewahrt werden, auch lokal aufbewahrt werden können, beispielsweise in dem Festplattenlaufwerk eines PCs. Durch Zuschalten der offenbarten Vorrichtung in ein Dateiensystem oder ein Anwendungsprogramm können Deltaströme anstelle eines Überschreibens von Dateien erzeugt werden. Somit kann ein Benutzer mehrere Versionen eines Dokuments lokal beibehalten, ohne einen übermäßigen Plattenspeicherplatz zu verwenden.
Diese und weitere wichtige Vorteile und Ziele der vorliegenden Erfindung werden in der beiliegenden Beschreibung, der Zeichnung und in den Patentansprüchen näher erörtert oder gehen aus denselben hervor.

Kurze Beschreibung der Zeichnungen

Ein veranschaulichendes und derzeit bevorzugtes Ausführungsbeispiel der Erfindung ist in der Zeichnung veranschaulicht. Es zeigen:
Fig. 1 ein Schema einer Vorrichtung zum Zusammenfügen einer Mehrzahl von sequentiellen Deltaströmen mit einem ursprünglichen Datenstrom, um einen revidierten Datenstrom zu erzeugen;
Fig. 2 einen Fluß von Operationen, die durch den Verbraucherprozeß der Fig. 1 durchgeführt werden können;
Fig. 3 einen Fluß von Operationen, die durch ein Transaktionselement der Fig. 1 bei einem Lesen eines Deltarahmens eines entsprechenden Deltastromes durchgeführt werden können;
Fig. 4 einen Fluß von Operationen, die durch ein Transaktionselement der Fig. 1 bei einem Laden eines Deltarahmens eines entsprechenden Deltastroms durchgeführt werden können;
Fig. 5 einen Fluß von Operationen, die durch ein Transaktionselement der Fig. 1 bei einem Vorrücken der Stromposition eines vorherigen Deltastromes durchgeführt werden können;
Fig. 6 einen Fluß von Operationen, die durch ein Transaktionselement der Fig. 1 bei einem Übertragen von Daten von einem ursprünglichen Datenstrom an einen negativen Deltastrom durchgeführt werden können;
Fig. 7 einen Fluß von Operationen, die durch ein Transaktionselement der Fig. 1 bei einem Erzeugen eines Umkehrungsübereinstimmungsrahmens für einen negativen Deltastrom durchgeführt werden können;
Fig. 8 einen Fluß von Operationen, die durch ein Transaktionselement durchgeführt werden können, das den abschließenden Rahmen seines entsprechenden Deltastromes geladen hat;
Fig. 9 drei Revisionen eines einfachen Satzes, drei Deltaströme, die die Revisionen darstellen, und drei negative Deltaströme, die durch die Vorrichtung der Fig. 1 erzeugt werden hätten können;
Fig. 10 ein Schema einer Vorrichtung zum Zusammenfügen einer sequentiellen Mehrzahl negativer Deltaströme mit einem aktualisierten Datenstrom, um einen gewünschten vorherigen Datenstrom zu rekonstruieren;
Fig. 11 ein Schema einer Vorrichtung zum Zusammenfügen einer sequentiellen Mehrzahl von Deltaströmen, um einen kompilierten Deltastrom zu erzeugen;
Fig. 12 einen Fluß von Operationen, die durch den Compiler-Verbraucherprozeß der Fig. 11 durchgeführt werden können;
Fig. 13 einen Fluß von Operationen, die durch ein Transaktionselement der Fig. 11 bei einem Konstruieren eines Übereinstimmungsrahmens in dem kompilierten Deltastrom durchgeführt werden können; und
Fig. 14 den kompilierten Deltastrom und drei negative Deltaströme, die durch die Vorrichtung der Fig. 11 während einer Zusammenfügung der drei Deltaströme der Fig. 9 erzeugt wurden.

Beschreibung des bevorzugten Ausführungsbeispiels

Ein Schema einer Computervorrichtung 20 zum Zusammenfügen einer sequentiellen Mehrzahl von Deltaströmen 30, 32, 34 mit einem ursprünglichen Datenstrom 36 ist allgemein in Fig. 1 gezeigt, die eine Transaktionskette 38 aufweisen kann, die eine Mehrzahl von sequenzierten Transaktionselementen 24, 26, 28 aufweist, wobei jedes Transaktionselement 24, 26, 28 eine Deltastromeingabe 42, 44, 46 aufweist, die einem der sequentiellen Mehrzahl von Deltaströmen 30, 32, 34 entspricht; und ein Verbraucherprozeß 22, der mit einem hinteren Element 24 der Transaktionskette 38 verbunden ist und eine Eingabe 48 für den ursprünglichen Datenstrom 36 und eine Ausgabe 50 für den aktualisierten Datenstrom 52 aufweist.
Ein Verfahren zum Zusammenfügen einer sequentiellen Mehrzahl von Deltaströmen 30, 32, 34 mit einem ursprünglichen Datenstrom 36 ist allgemein in den Flußdiagrammen der Fig. 2-8 gezeigt, die folgende Schritte aufweisen können: Einleiten einer Suchanforderung 102, in der sequentiellen Mehrzahl von Deltaströmen 30, 32, 34, nach einer Anzahl von Datenbytes, die an den aktualisierten Datenstrom 52 zu übertragen sind; Erfüllen 110 der Suchanforderung 102 mit Datenbytes, die durch den letzten Deltastrom in der sequentiellen Mehrzahl von Deltaströmen 30, 32, 34 bereitgestellt sind, die in der Lage ist, Datenbytes zu liefern; wenn die sequentielle Mehrzahl von Deltaströmen 30, 32, 34 nicht in der Lage ist, die Suchanforderung 102 zu erfüllen 110, Erfüllen 112 der Suchanforderung 102 mit Datenbytes, die durch den ursprünglichen Datenstrom 36 bereitgestellt sind; und Wiederholen der obigen Schritte, bis eine Suchanforderung 102 nicht erfüllt 110, 112 werden kann und der aktualisierte Datenstrom 52 vollständig 106 ist.
Nachdem die Vorrichtung 20 und das Verfahren zum Zusammenfügen einer sequentiellen Mehrzahl von Deltaströmen 30, 32, 34 mit einem ursprünglichen Datenstrom 36 allgemein beschrieben wurde, wird das System nun ausführlicher beschrieben.
Bei einem bevorzugten Ausführungsbeispiel weisen die Transaktionselemente 24, 26, 28 der Vorrichtung 20 ferner jeweils einen Deltastromleser, einen Vorheriges- Transaktionselement-Index, einen Vorheriger-Strom-Position- Überwacher, einen Aktueller-Rahmen-Puffer und eine I/O- Schnittstelle 66, 68, 70 zur Erfüllung einer Suchanforderung 102 auf.
Der Verbraucherprozeß 22 ist verantwortlich für ein Anfordern 102 von Daten für den aktualisierten Datenstrom 52 von der Kette 38 aus Transaktionselementen (Transaktionskette). Der Vorheriges-Transaktionselement-Index eines Transaktionselements 24, 26, 28 wird bei einem sequentiellen Ausbreiten der Suchanforderungen 102 des Verbraucherprozesses 22 durch die Transaktionskette 38 verwendet. Jede Suchanforderung 102 wird zunächst in dem hinteren Element 24 (TE2) der Transaktionskette 38, oder in demjenigen, das einer letzten Revision 30 des ursprünglichen Datenstroms 36 entspricht, eingeleitet 100. Als Antwort auf die Vorheriges-Transaktionselement-Indizes der Transaktionselemente 24, 26, 28 werden Suchanforderungen 102 durch zunehmend frühere Revisionen 40 des ursprünglichen Datenstroms 36 ausgebreitet, bis schließlich eine Suchanforderung 102 das Transaktionselement 28, das einer ersten Revision des ursprünglichen Datenstroms 34 entspricht (das 0-Element oder TE0), erreicht.
Die Deltastromeingabe 42, 44, 46 eines Transaktionselements 24, 26, 28 wird so reguliert, um 160 Deltarahmen (Übereinstimmungs- und/oder Datenrahmen) sequentiell von einem entsprechenden Deltastrom 30, 32, 34 in den aktuellen Rahmenpuffer 170 des Transaktionselements zu laden. Die bei einem Regulieren einer Deltastromeingabe 42, 44, 46 eines bestimmten Transaktionselements 24, 26, 28 durchgeführten Schritte sind in dem Flußdiagramm der Fig. 4 aufgelistet und werden in dieser Spezifikation später ausführlicher beschrieben.
Wenn ein Übereinstimmungsrahmen in einen aktuellen Rahmenpuffer 170 eines Transaktionselements 24, 26, 28 geladen 168 wird, wird die dem Rahmen zugeordnete Quellenübereinstimmungsposition mit der Vorheriger-Strom-Position, die durch das Transaktionselement 24, 26, 28 überwacht wird, verglichen. Ein Vorheriger-Strom-Position-Überwacher eines Transaktionselements 24, 26, 28 gibt an, wie viele Bytes des vorherigen Stromes 32, 34, 36 des Transaktionselements 24, 26, 28 verbraucht wurde. Der vorherige Strom 32, 34, 36 eines Transaktionselements 24, 26, 28 wird durch den Vorheriges-Transaktionselement-Index des Transaktionselements 24, 26, 28 identifiziert. Eine Quellenübereinstimmungsposition ist eine Zahl, die in einem Übereinstimmungsrahmen enthalten ist und angibt, wie viele Bytes eines vorherigen Stroms 40 verbraucht werden hätten sollen, bis ein bestimmter Übereinstimmungsrahmen in sein Transaktionselement 24, 26, 28 geladen wird. Wenn die Quellenübereinstimmungsposition größer ist als die Vorheriger-Strom-Position 172, wird eine zweite Suchanforderung 196 eingeleitet, um die Stromposition des vorherigen Stroms 32, 34, 36 um eine Anzahl von Bytes, die gleich dem Unterschied zwischen der Quellenübereinstimmungsposition und der Vorheriger-Strom-Position 172 ist (den Vorheriger-Strom-Verzögerungszählwert) vorzubewegen.
Die Deltastromleser sind verantwortlich dafür, die Deltarahmen (Übereinstimmungs- und/oder Datenrahmen) eines Deltastroms 30, 32, 34 zu lesen 130, nachdem sie in einen aktuellen Rahmenpuffer eines Transaktionselements 24, 26, 28 geladen 120 wurden. Ein Datenrahmen kann verwendet werden, um eine durch den Verbraucherprozeß 22 (über die Sucherfüllungs-I/O-Schnittstellen 66, 68, 70) eingeleitete Suchanforderung 102 zu erfüllen 136. Ein Übereinstimmungsrahmen bewirkt, daß die Suchanforderung 102 an ein vorheriges Transaktionselement 26, 28 geleitet 146 wird, oder wenn sich ein Übereinstimmungsrahmen in dem aktuellen Rahmenpuffer des letzten Transaktionselements 28 in der Transaktionskette 38 befindet, bewirkt der Übereinstimmungsrahmen, daß der Verbraucherprozeß 22 seine Anforderung 102 mit Daten aus dem ursprünglichen Datenstrom 36 erfüllt 112. Wenn eine Suchanforderung 102 an ein vorheriges Transaktionselement 26, 28 geleitet 146 wird, wird der Vorheriges- Transaktionselement(26, 28)-Index eines Transaktionselements 24, 26, 28 verwendet, um zu bestimmten, an welches Transaktionselement 26, 28 die Suchanforderung 102 geleitet 146 werden wird. Die durch den Deltarahmenleser ausgeführten Schritte sind in Fig. 3 umrissen.
Ein wichtiger Zusatz zu dem bevorzugten Ausführungsbeispiel der Computervorrichtung 20 ist die Einbeziehung von Negativer-Deltastrom-Schreibern 60, 62, 64 in jedes der Transaktionselemente 24, 26, 28. Ohne die Negativer-Deltastrom- Schreiber 60, 62, 64 sind die Datenbytes 172 eines vorherigen Stroms 32, 34, 36, die während des Vorbewegens eines vorherigen Stroms übersprungen werden (Fig. 5), verloren. Ein Negativer-Strom-Schreiber 60, 62, 64 wird durch das Vorbewegen eines vorherigen Stroms in Aktion gerufen, so daß übersprungene Datenbytes 172 (in Form eines Datenrahmens) in einen negativen Deltastrom 54, 56, 58, der einem bestimmten Deltastrom 30, 32, 34 zugeordnet ist, geschrieben 204 werden. Nachdem ein Datenrahmen in einen negativen Deltastrom 54, 56, 58 geschrieben 204 wurde, wird eine Übereinstimmungsrahmenumkehrung eines neu geladenen Übereinstimmungsrahmens in denselben negativen Deltastrom 54, 56, 58 geschrieben 178. Auf diese Weise liefern die negativen Deltaströme 54, 56, 58 Informationen zum Aufbauen einer Transaktionskette 38, um eine sequentielle Mehrzahl von negativen Deltaströmen 54, 56, 58 mit einem aktualisierten Deltastrom 52 zusammenzufügen, um einen gewünschten vorherigen Datenstrom 284 (ob es der ursprüngliche Datenstrom 36 oder die ursprüngliche Datei ist, oder irgendeine Zwischenrevision des ursprünglichen Datenstroms) wiederzuerlangen. Flußdiagramme für die Prozesse zum Übertragen 204, 178 von Datenrahmen- und Übereinstimmungsrahmenumkehrungen an einen negativen Deltastrom 54, 56, 58 sind in Fig. 6 bzw. 7 gezeigt.
Während die Vorrichtung 20 der Fig. 1 in einem programmierbaren Computer enthalten sein kann, ist die Vorrichtung 20 nicht auf ein solches Ausführungsbeispiel beschränkt. Die Vorrichtung 20 kann auch in einem physischen Speichermedium, wie z. B. einer Floppy-Disk, einem CD-ROM, einem Band oder dergleichen enthalten sein.
Bevorzugte Ausführungsbeispiele der oben erwähnten Prozeßschritte und -routinen werden nun noch ausführlicher beschrieben.
Der Verbraucherprozeß 22 ist verantwortlich für ein Aufbauen des aktualisierten Datenstroms 52. Siehe Fig. 2. Er fordert 102 wiederholt Daten von der Transaktionskette 38 (Kette aus Transaktionselementen) an. Alle Anforderungen 102 werden mit dem hinteren Element 24 (0-Element) der Transaktionskette 38 eingeleitet 100. Das hintere Element 24 ist dasjenige, das einen Deltastrom 30 liest, der eine letzte Revision eines ursprünglichen Datenstroms 36 bzw. einer ursprünglichen Datei, Datenbank oder dergleichen darstellt.
Ein Transaktionselement 24, 26, 28 kann auf eine von zwei Arten auf eine Anforderung 102 des Verbraucherprozesses 22 antworten 144, 136. Ein Transaktionselement 24, 26, 28 kann eine Anforderung 102 erfüllen 110, indem es Daten von einem aktuellen Datenrahmen (Daten von CURFRAMEBUF 170) zurücksendet 134 oder, alternativ dazu, indem es eine Anzahl, die eine Anzahl von Datenbytes darstellt, die von dem ursprünglichen Datenstrom 36 an den aktualisierten Datenstrom 52 übertragen 112 werden müssen, zurücksendet 144. Jegliche durch den Verbraucherprozeß 22 (durch die Transaktionskette 38) empfangenen 108 Daten werden an den aktualisierten Datenstrom 52 übertragen 110, 112. Der Verbraucherprozeß 22 fährt fort, Anforderungen 102 für Daten einzuleiten, bis die Transaktionskette 38 nicht in der Lage 104 ist, eine Anforderung 102 zu erfüllen, und der Verbraucherprozeß 22 folgert, daß der aktualisierte Datenstrom abgeschlossen 106 wurde.
Ein bevorzugter Fluß von Operationen für den Verbraucherprozeß der Fig. 1 ist in Fig. 2 gezeigt. Der Transaktionskontextindex (TCI - transaction context index) wird verwendet, um das Transaktionselement 24, an das eine Anforderung 102 gestellt werden wird, zu identifizieren 100. Was den Verbraucherprozeß 22 betrifft, wird die Anforderung 102 immer an das hintere Element 24 gestellt werden. Deshalb stellt 100 der Verbraucherprozeß 22 den Transaktionskontextindex auf eines weniger als der Transaktionszählwert (TRANSACTIONCNT) oder die Gesamtzahl von Transaktionselementen 24, 26, 28 in der Transaktionskette 38 ein. Man beachte, daß das Transaktionselement 24, das den Deltastrom 30, der die erste Revision des ursprünglichen Datenstroms 36 darstellt, bedient, als das 0-Element bezeichnet wird.
GOTCNT stellt die größte Anzahl von Datenbytes dar, die nach einer einzelnen Anforderung 102 des Verbraucherprozesses 22 an den aktualisierten Datenstrom 52 übertragen 110, 112 werden können. Wenn Daten durch ein Transaktionselement 24, 26, 28 zurückgesendet 134 werden, stellt GOTCNT die Gesamtanzahl von zurückgesendeten 136 Datenbytes dar. Die Datenbytes werden über einen Rücksendepuffer (RETURNBUF) zurückgesendet 134. Wenn die Transaktionskette 38 keine Daten von ihren aktuellen Rahmen liefern kann, aber immer noch Daten in dem ursprünglichen Datenstrom 36 verbleiben, stellt GOTCNT die Anzahl von Datenbytes dar, die von dem ursprünglichen Datenstrom 36 an den aktualisierten Datenstrom 52 zu übertragen 112 sind. Wenn der Verbraucherprozeß 22 eine Suchanforderung 102 einleitet, wird GOTCNT auf 0xFFFFFFFF eingestellt. Somit fragt der Verbraucherprozeß 22 die Transaktionskette 38 nach so vielen Bytes, wie überhaupt zurückgesendet 136, 144 werden können.

Lesen eines Deltarahmens

Der Rahmenleseprozeß kann durch ein beliebiges Transaktionselement 24, 26, 28 und in diversen Kontexten aufgerufen werden. Beispielsweise können Bytes aus dem aktuellen Rahmen eines Transaktionselements 24, 26, 28 als Antwort auf eine Suchanforderung 102 des Verbraucherprozesses 22 oder eine Suchanforderung 196 eines weiteren Transaktionselements 24, 26, 28, das gerade versucht, seine Vorheriger- Strom-Position vorzubewegen, gelesen werden.
Ein bevorzugter Fluß für den Rahmenleseprozeß, READ FRAME (Rahmenlesen) genannt, ist in Fig. 5 gezeigt.
Wenn der Verbraucherprozeß 22 eine Anforderung 102 bezüglich der größten Anzahl von Datenbytes einleitet, die die Transaktionskette 38 liefern kann, wird seine Anforderung 102 zunächst an das hintere Element 24 der Transaktionskette 38 geleitet 114. Das hintere Element 24 wird den Deltarahmen-Leseprozeß (Daten- und/oder Übereinstimmungsleseprozeß) einleiten. Siehe Fig. 3. Wenn alle Bytes 116, die durch einen aktuellen Rahmen eines Transaktionselements 24, 26, 28 dargestellt werden, verwendet 118 wurden, wird ein neuer Rahmen in den aktuellen Rahmenpuffer (CURFRAMEBUF = current frame buffer) des Transaktionselements 24, 26, 28 geladen 120. Wenn der Rahmenladeprozeß eine Ende-Der-Datei- Bedingung (EOF-Bedingung) 122 zurücksendet, wird ein GOTCNT von 0 an den Verbraucherprozeß 22 zurückgesendet 124, und das Aufbauen eines bestimmten aktualisierten Datenstroms ist abgeschlossen 106. Ansonsten bewirkt das Laden eines neuen Rahmens, daß die Anzahl von nicht verwendeten Bytes in einem aktuellen Rahmen (UNU = unused = nicht verwendet) auf die Länge des neu geladenen Rahmens (CFL) neu eingestellt 126 wird.
Nachdem gewährleistet ist, daß ein aktueller Rahmen geladen wurde und daß die Bytes eines Rahmens nicht entleert 118 wurden, wird GETCNT (eine lokale Variable des Rahmenlesen- Prozesses, die verwendet wird, um die GOTCNT-Anforderung- Variable zu aktualisieren) auf das Minimum der Anzahl von in einer Suche angeforderten 102 Bytes, oder die Anzahl von in einem aktuellen Rahmen verfügbaren 116, 126 Bytes eingestellt 128. Wenn der aktuelle Rahmen ein Datenrahmen 130 ist, wird eine GETCNT-Anzahl von Datenbytes in RETURNBUF kopiert 134 und an den Verbraucherprozeß 22 zurückgesendet 136. Wenn der aktuelle Rahmen kein Datenrahmen 130 ist, wird die Anforderung 102 des Verbraucherprozesses 22 an ein vorheriges Transaktionselement 26 weitergeleitet 146, und so weiter 28, bis entweder 1) Daten, die an den Verbraucherprozeß 22 zurückgesendet 134 werden können, in einem aktuellen Rahmen eines Transaktionselements 24, 26, 28 gefunden werden, oder 2) bestimmt 138 wird, daß keines der Transaktionselemente 24, 26, 28 Daten liefern kann, und eine positive GETCNT-Anzahl wird an den Verbraucherprozeß 22 zurückgesendet 144, was angibt, daß Daten von dem ursprünglichen Datenstrom 36 an den aktualisierten Datenstrom 52 übertragen 112 werden müssen. Wenn die Anforderung 102 des Verbraucherprozesses 22 an ein vorheriges Transaktionselement 26, 28 übertragen wird, führt dieses Element 26, 28 denselben Deltarahmen-Leseprozeß aus 148, der durch das hintere Element 24 ausgeführt wurde. Jedesmal, wenn der Rahmenleseprozeß durch ein Transaktionselement 24, 26, 28 eingeleitet wird, wird jedoch eine einzelne Kopie der lokalen Variablen, die dem Prozeß zugeordnet sind, in einem Transaktionskontext eines bestimmten Transaktionselements 24, 26, 28 gespeichert. Variablen eines Transaktionskontextes umfassen: TCI, CFL, UNU, CFU & PSP.
TCI wurde bereits als der Transaktionskontextindex definiert. CFU stellt die Anzahl verwendeter Bytes (Schriftzeichen) in einem aktuellen Rahmen dar. Das CFU jedes Transaktionselements, an das eine Suchanforderung geleitet wird, wird durch die zurückgesendete 136, 158 GETCNT- oder GOT- Anzahl inkrementiert 132, 154.
PSP (prior stream position) stellt die einem Transaktionselement 24, 26, 28 zugeordnete Vorheriger-Strom-Position dar und ist eine wichtige Variable bei einem Vorbewegen der Position eines vorherigen Stroms (diese Aufgabe wird in einem späteren Abschnitt ausführlicher beschrieben). Man beachte jedoch, daß die PSP jedes Transaktionselements 24, 26, 28, an das eine Suchanforderung geleitet wird, aber für die PSP eines Transaktionselements 24, 26, 28, das eine Suchanforderung 102 erfüllt 136, um die Anzahl von Bytes (GETCNT oder GOT), die an den Verbraucherprozeß 22 oder eine andere anfordernde Entität 24, 26, 28 zurückgesendet werden, vorbewegt 156 wird.
Andere Variablen, auf die in dem RAHMENLESEN-Fluß verwiesen 152 wird, lauten: F2_BEG, F2_END und CF.F2_BEG. F2_BEG und F2_END stellen die Anfangs- und Endadressen des aktualisierten Datenstroms dar, auf den durch einen aktuellen Übereinstimmungsrahmen Bezug genommen wird, und CF.F2_BEG stellt die nächste Adresse dar, die in dem aktualisierten Datenstrom 52 zu füllen ist. Diese Variablen weisen eine weitere Bedeutung auf, wenn eine Übereinstimmungsrahmenumkehrung erzeugt 176 wird, um in einen negativen Deltastrom 54, 56, 58 zu schreiben 178, oder wenn ein Übereinstimmungsrahmen aufgebaut 140 wird, um in einen kompilierten Deltastrom 294 zu schreiben.

Laden eines Deltarahmens

Wenn bestimmt 118 wird, daß die Anzahl nicht verwendeter Bytes (UNU) in einem aktuellen Deltarahmen eines Transaktionselements 24, 26, 28 null ist, muß ein neuer Rahmen als der aktuelle Rahmen des Transaktionselements 24, 26, 28 geladen 120 werden. Der Prozeß des Ladens eines neuen Deltarahmens ist in dem Flußdiagramm der Fig. 4 enthüllt.
Obwohl dies nicht an anderer Stelle in dieser Anmeldung erörtert wird, geht jedem Deltarahmen in einer Deltarahmensequenz eines Deltastroms 30, 32, 34 ein Rahmenanfangsblock voraus (oder, alternativ dazu, können die Anfangsblockinformationen in dem Rahmen enthalten sein). Der Rahmenanfangsblock wird gelesen 160, um zu bestimmen, ob ein Übereinstimmungsrahmen, Datenrahmen oder EOF-Rahmen angetroffen wurde. Wenn ein EOF-Rahmen geladen 162 wird, was für den Verbraucherprozeß 22 bedeutet 166, daß ein aktualisierter Datenstrom 52 vollständig 106 ist, gewährleistet ein Deltabeendigungsprozeß (DELTA TERMINATE-Prozeß) 164, daß jedes einzelne Transaktionselement 24, 26, 28 weiterhin seinen Deltastrom 30, 32, 34 liest, bis ein EOF-Rahmen erreicht 162 ist. Auf diese Weise werden negative Deltaströme 54, 56, 58 nicht in einem nicht fertiggestellten Zustand belassen.
Wenn ein neu geladener Rahmen ein Datenrahmen 168 ist, wird ein aktueller Rahmenpuffer (CURFRAMEBUF) eines Transaktionselements 24, 26, 28 mit den Datenbytes des Rahmens geladen 170.
Wenn ein Übereinstimmungsrahmen geladen 168 wird, wird eine Quellenübereinstimmungsposition (SMP = source match position), die dem Übereinstimmungsrahmen zugeordnet ist, mit der PSP des ladenden Transaktionselements 24, 26, 28 verglichen 172. Die Quellenübereinstimmungsposition gibt an, wie viele Bytes bereits aus einem Strom 32, 34, 36, der einem unmittelbar vorherigen Transaktionselement 26, 28 zugeordnet ist, verbraucht werden hätten sollen, bis der der bestimmten SMP zugeordnete Rahmen geladen wird. Wenn also eine SMP eines Übereinstimmungsrahmens die PSP seines Transaktionselements übersteigt, wird eine Anzahl von Bytes, die den Unterschied 172 (PSLC = prior stream lag count = Vorheriger-Strom-Verzögerungszählwert) darstellen, aus dem vorherigen Strom 32, 34, 36 verbraucht 174 worden sein müssen, bevor man mit der aktuellen Suchanforderung 102 des Verbraucherprozesses 22 fortfährt.
Nachdem ein vorheriger Strom vorbewegt 174 wurde und eine Anzahl von Datenbytes, die den PSLC darstellen (Daten, die zwischen aufeinanderfolgenden Revisionen des ursprünglichen Datenstroms gelöscht wurden), an einen bestimmten negativen Deltastrom 54, 56, 58 übertragen 204, 194, 202 wurden, wird eine Routine aufgerufen 176, die den neu geladenen Übereinstimmungsrahmen umkehrt und bewirkt, daß die Übereinstimmungsrahmenumkehrung in einen negativen Deltastrom 54, 56, 58 eines bestimmten Transaktionselements 24, 26, 28 geschrieben 178 wird. Eine Übereinstimmungsrahmenumkehrung ist ein Rahmen, der eine Umkehrungsübereinstimmungsbedingung angibt (d. h. welche Datenbytes in einem aktualisierten Datenstrom 52 mit den Bytes eines vorherigen Datenstroms 284 übereinstimmen).
Unabhängig davon, ob ein Daten- oder Übereinstimmungsrahmen als der neue aktuelle Rahmen eines Transaktionselements 24, 26, 28 geladen 120 wird, wird die Anzahl von verwendeten Bytes in dem aktuellen Rahmen (CFU) auf null neu eingestellt 180, und die Länge des aktuellen Rahmens (CFL = current frame's length) wird eingestellt 182, um die Anzahl von Bytes, auf die durch den neuen Rahmen Bezug genommen wird, darzustellen.

Vorbewegen der Anzahl von durch einen vorherigen Strom verbrauchten Bytes

Immer wenn das Laden 120 eines Übereinstimmungsrahmens einen positiven PSLC erzeugt 172, muß die Anzahl von Bytes, die aus einem Deltastrom 32, 34 eines vorherigen Transaktionselements 26, 28 verbraucht wurden, um den PSLC vorbewegt werden. Der Fluß VORHERIGEN STROM VORBEWEGEN der Fig. 5 zeigt die Schritte, die an einem Vorbewegen eines vorherigen Stroms 32, 34 eines Transaktionselements 26, 28 beteiligt sind, während diejenigen Schritte, die an einem Vorbewegen 194, 202 der Anzahl von durch den ursprünglichen Datenstrom 36 verbrauchten Bytes, beteiligt sind, in dem Flußdiagramm BASIS AN NEGATIVES DELTA ÜBERTRAGEN (Fig. 6) gezeigt sind.
Wenn bei 186 ein positiver PSLC verbleibt und wenn ein vorheriges Transaktionselement 26, 28 existiert 192, wird eine zweite Suchanforderung 196 eingeleitet, während die Suchanforderung 102 des Verbraucherprozesses 22 in der Schwebe gehalten wird. Die Anzahl von in der zweiten Suchanforderung angeforderten 196 Datenbytes wird durch die SKIPCNT- Variable, die anfänglich gleich PSLC ist, definiert. Die zweite Suchanforderung 196 erfordert das Ablaufenlassen zusätzlicher Instanzen des Rahmenleseprozesses der Fig. 3. Man beachte, daß der Rahmenleseprozeß sich selbst als Teil der zweiten Suchanforderung 196, im Zuge eines Versuchs, eine Anforderung 196 einer SKIPCNT-Anzahl von Datenbytes zu erfüllen 136, 144, aufrufen 148 kann. Über den RETURNBUF werden Daten an den Fluß VORHERIGEN STROM VORBEWEGEN zurückgesendet 200. Wenn Daten zurückgesendet 200 werden, werden sie in Form eines Datenrahmens in einen bestimmten negativen Deltastrom 54, 56, 58 geschrieben 204. Wenn eine positive GOTCNT-Zahl zurückgesendet wird, RETURNBUF jedoch leer ist, wird die Routine BASIS AN NEGATIVES DELTA ÜBERTRAGEN 202 verwendet, um Daten von dem ursprünglichen Datenstrom 36 an den bestimmten negativen Deltastrom 54, 56, 58 zu übertragen 212. Wenn eine zweite Suchanforderung 196 durch eine GOTCNT-Anzahl von Datenbytes lediglich teilweise erfüllt 204 wird, wird SKIPCNT um die GOTCNT-Anzahl verringert 206, und die Schritte des Flusses der Vorbewegung des vorherigen Stromes werden wiederholt.
Die Vorheriger-Strom-Position jedes Transaktionselements 24, 26, 28, das eine Positionsnummer in der Transaktionskette 38 aufweist, die geringer als die oder gleich der Zahl des Transaktionselements 24, 26, 28, das eine zweite Suchanforderung 196 einleitet, aber größer als die Zahl des Transaktionselements 24, 26, 28 (oder des Stroms 36), das die Anforderung 196 erfüllt, ist, wird um die Anzahl von Bytes, die an einen bestimmten negativen Deltastrom 54, 56, 58 übertragen 204, 194, 202 werden, erhöht 188, 208.
Eng verwandt mit der Routine VORHERIGEN STROM VORBEWEGEN ist die Routine BASIS AN NEGATIVES DELTA ÜBERTRAGEN. Wie zuvor angegeben wurde, wird die zweite Routine aufgerufen, wenn die Elemente 24, 26, 28 einer Transaktionskette 38 vor 40 einem bestimmten Element 24, 26, 28 nicht in der Lage sind, eine Anforderung 174, 196 für eine PSLC- (SKIPCNT)- Anzahl von Datenbytes zu erfüllen. Die Routine BASIS AN NEGATIVES DELTA ÜBERTRAGEN kann in bezug auf ein Zusammenfügen einer sequentiellen Mehrzahl von Deltaströmen 30, 32, 34 mit einem ursprünglichen Datenstrom 36 exzessiv wirken. Wenn jedoch eine sequentielle Mehrzahl von Deltaströmen 30, 32, 34 zusammengefügt wird, um einen kompilierten Deltastrom 294 zu erzeugen, ist der ursprüngliche Datenstrom 36 eventuell nicht verfügbar. Es ist deshalb notwendig, in einen negativen Deltastrom 288, 290, 292 einen Token 210, 212 aufzunehmen, der auf den fehlenden ursprünglichen Datenstrom 36 Bezug nimmt. Wenn der ursprüngliche Datenstrom 36 vorhanden ist, können Datenbytes aus dem ursprünglichen Datenstrom 36 verwendet werden, um den Basis- Stromreferenztoken (ursprünglichen Stromreferenztoken) zu füllen 214. PASSCHT ist die lokale Variable des Flusses BASIS AN NEGATIVES DELTA ÜBERTRAGEN, die anfänglich entweder der PSLC- oder SKIPCNT-Variablen ihrer Aufrufroutine gleich ist.

Erzeugung einer Übereinstimmungsrahmenumkehrung

Fig. 7 zeigt die Schritte, die am Erzeugen eines umgekehrten Übereinstimmungsrahmens oder einer Übereinstimmungsrahmenumkehrung beteiligt sind. Die Schritte beinhalten eine einfache algorithmische Umkehrung 218, wodurch ein Rahmen, der ein Segment in einem Deltastrom 30, 32, 34 angibt, das mit einem Segment in einem vorherigen Deltastrom 32, 34, 36 übereinstimmt, das eine vorherige Revision eines ursprünglichen Datenstromes 36 darstellt, "invertiert" (umgekehrt) wird, so daß der in einem negativen Deltastrom 54, 56, 58 aufgezeichnete 178 umgekehrte Übereinstimmungsrahmen ein Segment in einem negativen Deltastrom 54, 56, 58 angibt, das mit einem Segment in einem negativen Deltastrom 54, 56, 58 übereinstimmt, das eine vorherige Revision eines aktualisierten Datenstroms 52 darstellt.

Sicherstellen, daß jedes Transaktionselement alle Rahmen in seinem entsprechenden Deltastrom gelesen hat

Bis ein Ende-Der-Datei-Rahmen (EOF-Rahmen) durch ein Transaktionselement 24, 26, 28 erreicht 162 wird, wurde der aktualisierte Datenstrom 52 abgeschlossen 106. Die abschließenden Rahmen eines oder mehrerer Deltaströme 30, 32, 34 wurden jedoch möglicherweise nicht gelesen. Um sicherzustellen, daß alle negativen Deltaströme 54, 56, 58 abgeschlossen sind, wird ein Prozeß DELTA BEENDEN eingeleitet (Fig. 8).
Ein EOF-Rahmen umfaßt eine SMP, die auf das letzte Byte in dem Deltastrom 32, 34 des vorherigen Transaktionselements 56, 58 Bezug nimmt. Ein Vorheriger-Strom- Verzögerungszählwert (PSLC) wird als der Unterschied zwischen der SMP des EOF-Rahmens und der PSP des Transaktionselements 24, 26, 28, das den EOF-Rahmen lädt, berechnet. Durch ein Aufrufen der Routine VORHERIGEN STROM VORBEWEGEN der Fig. 5 werden vorherige Ströme 40 vorbewegt 224, wobei der PSLC als die Anzahl von Datenbytes verwendet wird, die noch in einem vorherigen Strom 32, 34, 36 zu lesen sind. Während in vorherigen Strömen 40 EOF-Rahmen angetroffen 228 werden, werden zusätzliche Instanzen der Routine DELTA BEENDEN durchgeführt, wodurch ein Welligkeitseffekt verursacht wird, der sicherstellt 232, daß alle Rahmen aller Deltaströme gelesen wurden.
Ein weiteres Verständnis des Verfahrens und der Vorrichtung 20 zum Zusammenfügen einer sequentiellen Mehrzahl von Deltaströmen 24, 26, 28 mit einem ursprünglichen Datenstrom 36 kann aus dem Beispiel der Fig. 9 gewonnen werden. Die Figur zeigt drei Revisionen 240, 242, 244 der einfachen Textdatei 238, "THIS IS A TEST PAGE" (DIES IST EINE TEST-SEITE). Im Anschluß an die drei Revisionen 240, 242, 244 liegen drei Deltaströme vor, die durch Anwendung des in der US- Patentanmeldung Seriennr. 08/039,702 von Squibb beschriebenen Verfahrens erzeugt werden. Die Datenrahmen weisen hinzugefügte Daten auf (eine Anpassung). Die Übereinstimmungsrahmen weisen eine Quellenübereinstimmungsposition (früher Dateiindex) auf, gefolgt von den Anfangs- (aktualisierter Dateiversatz) und Endbytes eines Segments in der revidierten Datei, die mit einem Segment in der vorherigen Datei übereinstimmt.
Unter Verwendung der drei Deltaströme, der ursprünglichen Textdatei 238 und der oben beschriebenen Vorrichtung 20 und des oben beschriebenen Verfahrens zum Zusammenfügen derselben kann die abschließende revidierte Textdatei 244 der Fig. 9 aufgebaut werden.
Das Zusammenfügen beginnt, während eine Transaktionskette 38 aufgebaut wird, und alle globalen und Transaktionskontextvariablen werden initialisiert. Die drei Revisionen 240, 242, 244 der Fig. 9, die durch Deltaströme 0, 1 und 2 dargestellt sind, entsprechen Transaktionselementen 0, 1 und 2 der Fig. 1.
Der Verbraucherprozeß 22 fordert so viele Datenbytes an 102, wie die Transaktionskette 38 liefern kann, und leitet seine Suche 102 in dem hinteren Transaktionselement 24 (TE2) ein. Da der aktuelle Rahmen von TE2 undefiniert ist, wird der erste Rahmen 258 des entsprechenden Deltastroms 30 als der aktuelle Rahmen von TE2 geladen 120. Beim Laden des Rahmens 258 wird eine Umkehrung des Übereinstimmungsrahmens in dem negativen Deltastrom 54 von TE2 aufgezeichnet 178. Ein Vorbewegen eines vorherigen Stroms tritt nicht auf, da die Quellenübereinstimmungsposition (SMP) des geladenen Übereinstimmungsrahmens 258 null ist. Der Übereinstimmungsrahmen 258 weist zehn Bytes auf, wodurch er bewirkt, daß eine Suchanforderung 102 nach zehn Datenbytes an TE1 geleitet 146 wird. TE1 lädt 120 seinen ersten Rahmen 252 und zeichnet 178 eine Umkehrung seines Übereinstimmungsrahmens in seinem entsprechenden negativen Deltastrom 56 auf. Wieder einmal ist die SMP des neuen Rahmens null, und es tritt kein Vorbewegen eines vorherigen Stroms auf. Der neu geladene Rahmen 252 von TE1 ist ein Übereinstimmungsrahmen von fünf Bytes, so daß die Suchanforderung 102 wieder (auf fünf Datenbytes) modifiziert 128 wird, bevor sie an TE0 geleitet 146 wird. Schließlich lädt 120 TE0 seinen ersten Deltarahmen 246, einen Übereinstimmungsrahmen 246 von zehn Bytes. Eine Umkehrung des Übereinstimmungsrahmens wird in dem negativen Deltastrom 58 von TE0 aufgezeichnet 178, aber es tritt kein Vorbewegen eines vorherigen Stroms auf. Da die aktuelle Rahmenlänge von TE0 von zehn Bytes größer ist als die angeforderte Anzahl von Datenbytes, modifiziert TE0 die Suchanforderung 102 nicht. Da es keine Daten zu liefern hat, sendet es die modifizierte Suchanforderung 102 nach fünf Datenbytes an den Verbraucherprozeß 22 zurück 144, indem es die Zahl fünf durch die Transaktionskette 38 zurück ausbreitet. Während die Zahl fünf an jedes Transaktionselement 26, 24 zurückgeleitet 144, 158 wird, wird die Vorheriger-Strom-Position (PSP) jedes Transaktionselements 26, 24 um fünf inkrementiert 156. Auf ein Empfangen seiner nicht- erfüllten Suchanforderung 102 hin überträgt 112 der Verbraucherprozeß 22 die ersten fünf Datenbytes der ursprünglichen Textdatei 238 (THIS_) an die aktualisierte Textdatei 52.
Nun wird eine weitere Suchanforderung 102 durch den Verbraucherprozeß 22 eingeleitet. Da der aktuelle Rahmen von TE2 ein Übereinstimmungsrahmen 258 mit fünf nichtverwendeten Bytes ist, wird die Suchanforderung 102 modifiziert 128 und weitergeleitet 146. TE1, das die fünf Bytes seines aktuellen Übereinstimmungsrahmens 252 entleert hat, lädt 120 den zweiten Deltarahmen 254 seines Deltastroms 32. Der zweite Rahmen 254 ist ein Datenrahmen, und die Suchanforderung 102 wird mit fünf Datenbytes (COULD) erfüllt 134, 136.
Während die Daten durch die Transaktionskette 38 zurückgesendet werden, steigt die PSP von TE2 von fünf auf zehn. Während der dritten Anforderung 102 des Verbraucherprozesses 22 muß TE2 einen neuen Deltarahmen laden 120. Da der neue Rahmen 260 ein Datenrahmen ist, wird sein gesamter Inhalt (_B) an den Verbraucherprozeß 22 zurückgesendet 134. Die aktualisierte Textdatei 52 liest sich nun "THIS_COULD_B".
Eine nächste Anforderung 102 des Verbraucherprozesses 22 veranlaßt TE2, den dritten Rahmen 262 seines Deltastroms 30 zu laden. Da der Rahmen 262 ein Übereinstimmungsrahmen ist, wird die SMP des Rahmens 262 mit der PSP von TE2 verglichen, und es wird bestimmt 172, daß der Strom 32, der sich vor TE2 befindet, um fünf Bytes vorbewegt werden muß (15- 10=5). Eine zweite Suchanforderung 196 nach fünf Bytes wird in den Strömen 40, die vor TE2 auftreten, eingeleitet. Da der aktuelle Datenrahmen 254 von TE1 die gesamten in der zweiten Suche 196 angeforderten fünf Bytes liefern kann und die notwendige Vorbewegung der PSP von TE2 erfüllen kann, wird die zweite Suchanforderung 196 beendet 190. Die durch TE1 (N'T_B) zurückgesendeten fünf Bytes werden in den negativen Deltastrom 54 von TE2 geschrieben 204. Nachdem es seine PSP auf fünfzehn vorbewegt hat, zeichnet TE2 die Umkehrung seines neu geladenen Übereinstimmungsrahmens 262 in seinem negativen Deltastrom 54 auf 178, verringert die angeforderte Anzahl von Bytes des Verbraucherprozesses auf fünfzehn (die Länge seines aktuellen Übereinstimmungsrahmens) und leitet 146 die Anforderung 102 an TE1. TE1 kann vier Datenbytes(E_A_) von seinem aktuellen Datenrahmen 254 liefern. Während die Daten an den Verbraucherprozeß 22 zurückgesendet 136 werden, wird die PSP von TE2 auf neunzehn inkrementiert 156.
Die nächste Anforderung 102 des Verbraucherprozesses 22 wird durch TE2 geleitet 146, wobei sie auf elf reduziert 128 wird. TE1 muß nun einen neuen Deltarahmen laden 120. Da sein nächster verfügbarer Rahmen ein Übereinstimmungsrahmen 256 ist, bestimmt es, daß die SMP des neuen Rahmens 256 größer ist als seine PSP (10-5=5), und der vorherige Strom muß um fünf Bytes vorbewegt 174 werden. Da TE0 in seinem Übereinstimmungsrahmen 246 fünf Bytes übrig hat, müssen die nächsten fünf Bytes der ursprünglichen Textdatei 238 (IS_A_) an den negativen Deltastrom 56 von TE1 übertragen 194 werden. Durch ein Zurücksenden der Daten durch die Transaktionskette 38 wird die PSP von TE0 auf zehn inkrementiert 156, und die PSP von TE1 wird ebenfalls auf zehn inkrementiert 156. Eine Umkehrung des neuen Übereinstimmungsrahmens 256 von TE1 wird in seinem negativen Deltastrom 56 aufgezeichnet 178. Da der neu geladene Übereinstimmungsrahmen 256 von TE1 länger ist als elf Bytes, wird die Suchanforderung 102 des Verbraucherprozesses 22 unmodifiziert an TE0 geleitet 146. Es ist erforderlich, daß TE0 den nächsten Rahmen 248 seines Deltastroms 34 lädt 120. Der Rahmen 248 ist ein Datenrahmen von acht Bytes, so daß die Suchanforderung 102 modifiziert 128 wird, und acht Datenbytes (RADICAL_) durch die Transaktionskette 38 zurückgesendet 136 werden. Die PSP von TE1 wird auf achtzehn inkrementiert 156, und die PSP von TE2 wird auf siebenundzwanzig inkrementiert 156. Die aktualisierte Textdatei 52, die durch den Verbraucherprozeß 22 erzeugt wird, liest sich nun "THIS_COULD_BE_A_RADICAL_".
Eine weitere Anforderung 102 des Verbraucherprozesses 22 wird auf eine Anforderung 102 nach drei Datenbytes reduziert 128, während sie durch TE2 geleitet 146 wird. Die Anforderung 102 nach drei Datenbytes wird ohne Modifizierung durch TE1 geleitet 146. Auf ein Erreichen von TE0 hin wird die Suchanforderung 102 in der Schwebe gehalten, während TE0 den letzten Rahmen 250 seines Deltastroms 34 lädt 120. Da die SMP des geladenen Übereinstimmungsrahmens 250 gleich der PSP von TE0 ist (10=10), tritt ein Vorbewegen eines vorherigen Stroms nicht auf. Jedoch wird eine Umkehrung des Übereinstimmungsrahmens in dem negativen Deltastrom 58 von TE0 aufgezeichnet 178. Die Anforderung 102 nach drei Datenbytes wird unerfüllt an den Verbraucherprozeß 22 zurückgesendet 144. Während sie zurückgesendet wird, steigt die PSP von TE1 auf einundzwanzig an, und die PSP von TE2 steigt auf dreißig an. Die nächsten drei Bytes (TES) der ursprünglichen Textdatei 238 werden an die aktualisierte Textdatei 52 übertragen 112.
Die nächste Anforderung 102 des Verbraucherprozesses 22 wird durch die zwei Bytes (T.) eines neu geladenen Datenrahmens 264 von TE2 erfüllt 134, 136.
Eine abschließende Anforderung 102 des Verbraucherprozesses 22 wird unerfüllt zurückgesendet, nachdem sie auf null verringert wurde, als TE2 ein Erreichen des Endes 122 seines Datenstroms 30 bestätigte. Der Verbraucherprozeß 22 schloß somit sein Aufbauen der aktualisierten Textdatei 244, "THIS_COULD_BE_A_RADICAL_TEST", ab.
Wenn TE2 ein Erreichen des Endes seines Deltastroms 30 bestätigt 166, wird ein Welligkeitseffekt ausgelöst, der bewirkt, daß die anderen Transaktionselemente 26, 28 das Lesen ihrer eigenen Deltaströme 32, 34 abschließen 224 und das Aufbauen ihrer negativen Deltaströme 56, 58 vollenden 232.
Bei diesem Prozeß werden die letzten sieben Schriftzeichen der ursprünglichen Textdatei 238 (T_PAGE.) als Datenrahmen in den negativen Deltastrom 54 von TE2 geschrieben.
Man sollte verstehen, daß, während das obige Beispiel ein Zusammenfügen von drei Deltaströmen 30, 32, 34 mit einem ursprünglichen Datenstrom 36 einleitete, das obige Verfahren und die obige Vorrichtung 20 ohne weiteres einen bis viele Deltaströme mit einem ursprünglichen Datenstrom 36 zusammenfügen. Die Anzahl von zusammenzufügenden Strömen wird lediglich durch die Fähigkeiten einer gegebenen CPU begrenzt.
Wenn man wünschte, den obigen Zusammenfügungsprozeß umzukehren und die ursprüngliche Textdatei 238 der Fig. 9 neu aufzubauen, wobei lediglich die aktualisierte Textdatei 244 und die drei negativen Deltaströme 54, 56, 58 zur Verfügung stehen, könnte die Computervorrichtung 20 die Transaktionskette 38 der Fig. 10 aufbauen. Man beachte, daß die negativen Deltaströme 54, 56, 58 in einer umgekehrten Reihenfolge mit den Transaktionselementen 24, 26, 28 verbunden sind und daß keine Negative der negativen Deltaströme 54, 56, 58 erzeugt werden (in Wirklichkeit sind die Negativer- Deltastrom-Schreiber mit Null-Vorrichtungen verbunden. Bei einem schrittweisen Durchlaufen des Verfahrens der Fig. 2- 8 könnte die ursprüngliche Textdatei 238 neu aufgebaut werden. Desgleichen könnte eine Transaktionskette, die lediglich negative Deltaströme 2 und 1 aufweist, verwendet werden, um die erste Revision 240 (einen gewünschten vorherigen Datenstrom 284) der ursprünglichen Textdatei 238 neu aufzubauen.
Das oben beschriebene Verfahren und die oben beschriebene Vorrichtung 20 können, mit einigen geringfügigen Modifikationen, ebenfalls verwendet werden, um eine sequentielle Mehrzahl von Deltaströmen 30, 32, 34 zusammenzufügen, um einen kompilierten Deltastrom 294 zu erzeugen. Statt Datenbytes an einen aktualisierten Datenstrom 52 zu übertragen, werden Deltarahmen (Daten- und/oder Übereinstimmungsrahmen) an einen kompilierten Deltastrom 294 übertragen 306, 308.
Die Modifizierungen, die an der Vorrichtung 20 der Fig. 1 durchgeführt werden müssen, umfassen die Ersetzung einer Verbindung des Verbraucherprozesses 22 und des aktualisierten Datenstroms 52 durch eine Verbindung des Compiler- Verbraucherprozesses 286 und des kompilierten Deltastroms 294. Diese Modifizierungen sind in der Vorrichtung 334 der Fig. 11 gezeigt. Zusätzlich sind die Verbindungen des ursprünglichen Datenstroms 48 entfernt. Die einzige Änderung des Verfahrens ist eine Änderung des Flusses von Operationen in dem Compiler-Verbraucherprozeß 286, wie unten ausgeführt wird.

Compiler-Verbraucherprozeß

Der Compiler-Verbraucherprozeß 286 ist für ein Aufbauen des kompilierten Deltastroms 294 verantwortlich und ist in bezug auf die meisten Aspekte dem Verbraucherprozeß 22 ähnlich, der einen aktualisierten Datenstrom 52 aufbaut. Wiederum fordert er wiederholt Daten von der Transaktionselementkette 38 an 298, und alle Anforderungen 298 werden an das hintere Element 24 der Kette 38 eingeleitet 296. Die Transaktionselemente 24, 26, 28 sprechen auf dieselbe Weise auf den Compiler-Verbraucherprozeß 286 an, auf die sie auf eine Anforderung 102 von einem standardmäßigen Verbraucherprozeß 22 ansprechen würden. Es bestehen jedoch leichte Unterschiede. Wenn Daten durch ein Transaktionselement 24, 26, 28 zurückgesendet 304 werden, werden sie als ein Datenrahmen in den kompilierten Deltastrom 294 kopiert 306. Die Datenbytes des Datenrahmens werden nicht extrahiert. Dies liegt daran, daß ein "Deltastrom" 294, und nicht ein "Datenstrom" 52 kompiliert wird. Wenn die Transaktionskette 38 eine positive GOTCNT-Anzahl zurücksendet, werden Daten nicht von dem ursprünglichen Datenstrom 36 übertragen, da eine Verbindung mit diesem Strom eventuell nicht existiert. Anstatt Daten von dem ursprünglichen Datenstrom 36 zu übertragen, wird ein Übereinstimmungsrahmen, der auf den ursprünglichen Datenstrom 36 Bezug nimmt, in den kompilierten Deltastrom 294 geschrieben 308.
Der Compiler-Verbraucherprozeß 286 leitet weiterhin Anforderungen 298 ein, bis die Transaktionselemente 24, 26, 28 das Ende ihrer Deltaströme 30, 32, 34 erreichen und nicht in der Lage sind 302, eine Anforderung 298 zu erfüllen 306 oder eine positive GOTCNT-Anzahl zurückzusenden 308.
Ein bevorzugter Fluß von Operationen für den Compiler- Verbraucherprozeß 286 der Fig. 11 ist in Fig. 12 gezeigt. Die Variablen in dem Flußdiagramm der Fig. 12 sind mit denjenigen in der Fig. 2 für den standardmäßigen Verbraucherprozeß 22 identisch.
Der Rahmenleseprozeß (Fig. 3), der durch den Compiler- Verbraucherprozeß 286 aufgerufen wird, ist identisch mit dem zuvor beschriebenen Rahmenleseprozeß. Jedoch wird nun das Ergebnis 312 des Prozesses Übereinstimmungsrahmen aufbauen, das zuvor ignoriert wurde, verwendet, wenn ein Übereinstimmungsrahmen in den kompilierten Deltastrom 294 geschrieben 308 wird. Wie zuvor angegeben wurde, wird in einem kompilierten Deltastrom 294 ein Übereinstimmungsrahmen aufgebaut 140, statt Daten von einem ursprünglichen Datenstrom 36 an den kompilierten Deltastrom 294 zu übertragen. Der Prozeß des Aufbauens 310 eines Übereinstimmungsrahmens in einem kompilierten Deltastrom 294 wird unten beschrieben.

Aufbauen eines Übereinstimmungsrahmens in einem kompilierten Deltastrom

Wenn eine Suchanforderung 298 des Compiler- Verbraucherprozesses 286 durch die Transaktionskette 38 geleitet wird und keines der Transaktionselemente 24, 26, 28 in der Lage ist, Daten an den Compiler-Verbraucherprozeß 286 zurückzusenden, muß ein Übereinstimmungsrahmen aufgebaut 310 werden, so daß der kompilierte Deltastrom 294 in der Lage sein wird, einen Verbraucherprozeß 22 anzuweisen, wann Daten aus einem ursprünglichen Datenstrom 36 zu ziehen sind.
Ein Fluß von Operationen für den Prozeß eines Aufbaus eines Übereinstimmungsrahmens ist in Fig. 13 gezeigt. Der Prozeß eines Aufbaus eines Übereinstimmungsrahmens wird immer durch TE0, das Transaktionselement 28 am Ende der Transaktionskette 38, aufgerufen, wie in dem Rahmenlesen-Fluß der Fig. 3 gezeigt ist. Die Routine Übereinstimmungsrahmen aufbauen verwendet eine Kombination der Transaktionskontextvariablen des sie aufrufenden Transaktionselements 28 und ferner die Transaktionskontextvariablen des hinteren Elements 24 (TE2 in Fig. 11). Definitionen für Variablen der Fig. 13, die nirgendwo sonst in dieser Spezifizierung definiert sind, lauten wie folgt:
SERVCNT: die Anzahl von Schriftzeichen, die durch den aufgebauten Übereinstimmungsrahmen darzustellen sind
CF.F2_BEG: die Anfangsadresse des aktuellen Deltarahmens für das hintere Transaktionselement 28 (TE2 in Fig. 11)
Ein weiteres Verständnis des Verfahrens und der Vorrichtung 334 zum Zusammenfügen einer sequentiellen Mehrzahl von Deltaströmen 30, 32, 34, um einen kompilierten Deltastrom 294 zu erzeugen, kann aus dem Beispiel der Fig. 14 gewonnen werden. Das Beispiel basiert auf den drei Revisionen 240, 242, 244 der einfachen Textdatei 238 der Fig. 9. Die drei Deltaströme 30, 32, 34, die durch eine Anwendung des in der US-Patentanmeldung Seriennr. 08/039,702 von Squibb beschriebenen Verfahrens erzeugt werden, werden in Fig. 14 wiederholt. Unter Verwendung der drei Deltaströme 30, 32, 34 und der oben beschriebenen Vorrichtung 334 und des oben beschriebenen Verfahrens zum Zusammenfügen derselben kann der kompilierte Deltastrom 294 der Fig. 14 aufgebaut werden.
Das Zusammenfügen beginnt wiederum mit dem Aufbau einer Transaktionskette 38 und einer Initialisierung aller globalen und kontextabhängigen Variablen. Deltaströme 0, 1 und 2 entsprechen den Transaktionselementen 0, 1 und 2 der Fig. 11.
Der Compiler-Verbraucherprozeß 286 fordert so viele Datenbytes an 298, wie die Transaktionskette 38 liefern kann, und leitet seine Suche 298 in dem hinteren Transaktionselement TE2 ein 296. Wie bei dem Zusammenfügen der Deltaströme 30, 32, 34 mit einem ursprünglichen Datenstrom 36 veranlaßt die erste Anforderung 298 des Compiler-Verbraucherprozesses 286 jedes Transaktionselement 24, 26, 28 in der Kette 38, seinen ersten Deltarahmen 246, 252, 258 zu laden und eine Übereinstimmungsrahmenumkehrung 266, 270, 276 in seinen entsprechenden negativen Deltastrom 288, 290, 292 zu schreiben 178. Wenn die Suchanforderung 298 (nachdem sie zu einer Anforderung 298 nach fünf Datenbytes modifiziert 128 wurde) TE0 erreicht und nicht erfüllt werden kann, wird ein Übereinstimmungsrahmen 318, der auf den ursprünglichen Datenstrom 36 Bezug nimmt, aufgebaut 140, und die modifizierte Suchanforderung 298 nach fünf Datenbytes wird durch die Transaktionskette 38 zu dem Compiler-Verbraucherprozeß 286 zurück ausgebreitet. Da die Zahl fünf an jedes Transaktionselement 24, 26, 28 zurückgeleitet wird, wird die Vorheriger-Strom-Position (PSP) jedes Transaktionselements 24, 26, 28 um fünf inkrementiert 156. Auf ein Empfangen seiner unerfüllten 304 Suchanforderung 298 hin zeichnet der Compiler-Verbraucherprozeß 286 den aufgebauten Übereinstimmungsrahmen 318 in dem kompilierten Deltastrom 294 auf 308.
Eine weitere Suchanforderung 298 wird nun durch den Compiler-Verbraucherprozeß 286 eingeleitet. Da der aktuelle Rahmen von TE2 ein aktueller Übereinstimmungsrahmen 258 mit fünf nicht verwendeten Bytes ist, wird die Suchanforderung 298 modifiziert 128 und weitergeleitet 146. Nachdem TE1 die fünf Bytes seines aktuellen Übereinstimmungsrahmens entleert hat, lädt es den zweiten Deltarahmen 254 seines Deltastroms 32. Der zweite Rahmen 254 ist ein Datenrahmen, und die Suchanforderung 298 wird mit fünf Bytes von Daten 320 (COULD) erfüllt 134, 136. Während die Anzahl von Datenbytes durch die Transaktionskette 38 zurückgesendet wird, steigt 156 die PSP von TE2 von fünf auf zehn.
Während der dritten Anforderung 298 des Compiler- Verbraucherprozesses 286 muß TE2 einen neuen Deltarahmen laden. Da der neue Rahmen 260 ein Datenrahmen ist, wird sein gesamter Inhalt (B) an den Compiler-Verbraucherprozeß 286 zurückgesendet 134 und als Datenrahmen 322 in den kompilierten Deltastrom 294 geschrieben 306.
Eine nächste Anforderung 298 des Compiler- Verbraucherprozesses 286 veranlaßt TE2, den dritten Rahmen 262 seines Deltastroms 30 zu laden. Da der Rahmen 262 ein Übereinstimmungsrahmen ist, wird die SMP des Rahmens mit der PSP von TE2 verglichen, und es wird bestimmt 172, daß der Strom 32, der sich vor TE2 befindet, um fünf Bytes (15- 10=5) vorbewegt werden muß. Eine zweite Suchanforderung 196 nach fünf Bytes wird in den Strömen 32, 34 vor TE2 eingeleitet. Da der aktuelle Datenrahmen 254 von TE1 die gesamten in der zweiten Suche 196 angeforderten fünf Bytes liefern und die notwendige Vorbewegung der PSP von TE2 erfüllen kann, wird die zweite Suchanforderung 296 beendet. Die durch TE1 (N'T_B) zurückgesendeten fünf Bytes werden in Form eines Datenrahmens 278 in den negativen Deltastrom 288 von TE2 geschrieben 204. Nachdem es seine PSP zu 15 vorbewegt hat, zeichnet TE2 die Umkehrung seines neu geladenen Übereinstimmungsrahmens 262 in seinem negativen Deltastrom 288 auf 178, verringert 128 es die Anzahl von angeforderten Bytes des Compiler-Verbraucherprozesses auf fünfzehn (die Länge seines aktuellen Übereinstimmungsrahmens 262) und leitet 146 die Anforderung 298 an TE1. TE1 kann vier Bytes von Daten (E_A_) von seinem aktuellen Datenrahmen 254 liefern. Während die Daten 324 an den Compiler- Verbraucherprozeß 286 zurückgesendet werden, wird die PSP von TE2 auf neunzehn inkrementiert 156.
Die nächste Anforderung 298 des Compiler- Verbraucherprozesses 286 wird durch TE2 geleitet 146, wobei sie auf elf verringert 128 wird. TE1 muß nun einen neuen Deltarahmen laden 120. Da sein nächster verfügbarer Rahmen ein Übereinstimmungsrahmen 256 ist, bestimmt 172 es, daß die SMP des neuen Rahmens 256 größer ist als seine PSP (10- 5=5) und der vorherige Strom 34 muß um fünf Bytes vorbewegt werden. Da TE0 in seinem Übereinstimmungsrahmen 246 fünf Bytes übrig hat und keine Daten liefern kann, muß ein Referenztoken eines ursprünglichen Datenstroms 36 in dem negativen Deltastrom 290 von TE1 aufgezeichnet 212 werden. Auf ein Zusammenfügen des ursprünglichen Datenstroms 36 mit dem kompilierten Deltastrom 294 hin kann der in dem negativen Deltastrom 290 von TE1 aufgezeichnete 212 Referenztoken mit den geeigneten Daten von dem ursprünglichen Datenstrom 36 gefüllt 214 werden. Durch ein Zurücksenden der Anzahl von Bytes in dem Referenztoken durch die Transaktionskette 38 wird die PSP von TE0 auf zehn inkrementiert 156, und die PSP von TE1 wird auf zehn inkrementiert 156. Eine Umkehrung des neuen Übereinstimmungsrahmens 256 von TE1 wird in seinem negativen Deltastrom 290 aufgezeichnet 178. Da der neu geladene Übereinstimmungsrahmen 256 von TE1 länger ist als elf Bytes, wird die Suchanforderung 298 des Compiler- Verbraucherprozesses 286 unmodifiziert an TE0 geleitet 146. Es ist erforderlich, daß TE0 den nächsten Rahmen 248 seines Deltastroms 34 lädt 120. Der Rahmen 248 ist ein Datenrahmen von acht Bytes. Die Suchanforderung 298 wird modifiziert 128, und acht Datenbytes (RADICAL_) werden durch die Transaktionskette 38 zurückgesendet. Die PSP von TE1 wird auf achtzehn inkrementiert 156, und die PSP von TE2 wird auf siebenundzwanzig inkrementiert 156. Die acht zurückgesendeten Datenbytes werden als ein Datenrahmen 326 in dem kompilierten Deltastrom 294 aufgezeichnet 306.
Eine weitere Anforderung 298 des Compiler- Verbraucherprozesses 286 wird zu einer Anforderung 298 nach drei Datenbytes reduziert 128, während sie durch TE2 geleitet 146 wird. Die Anforderung 298 nach drei Datenbytes wird ohne Modifizierung durch TE1 geleitet 146. Auf ein Erreichen von TE0 hin wird die Suchanforderung 298 in der Schwebe gehalten, während TE0 den letzten Rahmen 250 seines Deltastroms 34 lädt 120. Da die SMP des geladenen Übereinstimmungsrahmens 250 gleich der PSP (10=10) von TE0 ist, tritt kein Vorbewegen eines vorherigen Stroms auf. Eine Umkehrung des geladenen Übereinstimmungsrahmens 250 wird in dem negativen Deltastrom 292 von TE0 aufgezeichnet 178. Wiederum muß TE0 einen Übereinstimmungsrahmen, der auf den ursprünglichen Datenstrom 36 Bezug nimmt, aufbauen 140. Die Anforderung 298 nach drei Datenbytes wird unerfüllt an den Compiler-Verbraucherprozeß 286 zurückgesendet. Während sie zurückgesendet wird, steigt die PSP von TE1 auf einundzwanzig an 156, und die PSP von TE2 steigt auf dreißig an 156. Der aufgebaute Übereinstimmungsrahmen 328 wird in dem kompilierten Deltastrom 294 aufgezeichnet 308.
Die nächste Anforderung 298 des Compiler- Verbraucherprozesses 286 wird mit einem Datenrahmen 330, der die zwei Bytes (T.) eines neu geladenen Datenrahmens 264 von TE2 darstellt, erfüllt.
Eine abschließende Anforderung 298 des Compiler- Verbraucherprozesses 286 wird unerfüllt zurückgesendet, nachdem sie auf null reduziert wurde, als TE2 ein Erreichen des Endes seines Deltastroms 30 bestätigte 122. Der Compiler-Verbraucherprozeß 286 schloß somit sein Aufbauen des kompilierten Deltastroms 294 ab 302.
Wie bei dem Zusammenfügen von Deltaströmen 30, 32, 34 mit einem ursprünglichen Datenstrom 36, wenn TE2 ein Erreichen des Endes seines Deltastroms 30 bestätigt 122, wird ein Welligkeitseffekt 164 ausgelöst, der bewirkt, daß die anderen Transaktionselemente 26, 28 das Lesen ihrer eigenen Deltaströme 32, 34 abschließen und das Aufbauen ihrer negativen Deltaströme 290, 292 vollenden. Während dieses Prozesses wird ein weiterer Referenztoken 316, dieses Mal einer, der auf die letzten sieben Bytes des ursprünglichen Datenstroms 36 Bezug nimmt, in dem negativen Deltastrom 288 von TE2 aufgezeichnet 204.
Obwohl die hierin erörterten Deltaströme 30, 32, 34 Deltarahmen aufweisen, die auf übereinstimmende und/oder hinzugefügte Datenbytes Bezug nehmen, könnten Fachleute das offenbarte Verfahren und die offenbarte Vorrichtung 20, 332, 334 ohne weiteres in Verbindung mit Deltaströmen verwenden, die Bezugnahmen auf übereinstimmende und/oder hinzugefügte Datenzeilen aufweisen. Die Schriftzeichen eines Übereinstimmungsrahmens würden sich deshalb auf Zeilenadressen, und nicht auf Byteadressen, beziehen.
Die obige Beschreibung beschreibt ein Verfahren und eine Vorrichtung 20, 332, 334 zum Zusammenfügen einer sequentiellen Mehrzahl von Deltaströmen 30, 32, 34. Da die Deltaströme 30, 32, 34 eine Sequenz von nicht überlappenden Übereinstimmungs- und/oder Datenrahmen aufweisen, liefert das System außergewöhnliche Ergebnisse, wenn alle Ströme 30, 32, 34 in sequentiellen Speichermedien gespeichert (und in dieselben geschrieben) sind. Es ist kein anderes Delta- Zusammenfügungssystem bekannt, das in einer Umgebung arbeitet, die lediglich sequentielle Speichermedien aufweist.
Während veranschaulichende und derzeit bevorzugte Ausführungsbeispiele des Verfahrens und der Vorrichtung 20, 332, 334 hierin ausführlich beschrieben werden, versteht es sich, daß die offenbarten Konzepte ansonsten auf verschiedene Weise angewandt und eingesetzt werden können, und daß die beigefügten Patentansprüche so auszulegen sind, daß sie solche Abwandlungen umfassen, jedoch nur soweit, wie sie nicht durch den Stand der Technik begrenzt sind.

Claims

1. Ein Verfahren zum Zusammenfügen eines ursprünglichen Datenstroms (36) mit einer sequentiellen Mehrzahl von Deltaströmen (30, 32, 34), um einen aktualisierten Datenstrom (52) in einem programmierbaren Computer aufzubauen, wobei das Verfahren folgende Schritte aufweist:

a) Einleiten einer Suchanforderung (102), in der sequentiellen Mehrzahl von Deltaströmen (30, 32, 34), nach einer Anzahl von Datenbytes, die an den aktualisierten Datenstrom (52) zu übertragen sind;

b) Erfüllen (110) der Suchanforderung (102) mit Datenbytes, die durch den letzten Deltastrom in der sequentiellen Mehrzahl von Deltaströmen (30, 32, 34) bereitgestellt werden, der in der Lage ist, Datenbytes zu liefern,;

c) wenn die sequentielle Mehrzahl von Deltaströmen (30, 32, 34) nicht in der Lage ist, die Suchanforderung (102) zu erfüllen (110), Erfüllen (112) der Suchanforderung (102) mit Datenbytes, die durch den ursprünglichen Datenstrom (36) bereitgestellt werden; und

d) Wiederholen der Schritte a) - c), bis eine Suchanforderung (102) nicht erfüllt (110, 112) werden kann und der aktualisierte Datenstrom (52) vollständig (106) ist.

2. Ein Verfahren gemäß Anspruch 1, das Vor dem Schritt a) folgenden Schritt aufweist: Aufbauen einer Kette (38) aus Transaktionselementen (24, 26, 28), die der sequentiellen Mehrzahl von Deltaströmen (30, 32, 34) entsprechen, wobei ein mit der höchsten Nummer versehenes Transaktionselement (24) in der Transaktionskette (38) einem Deltastrom (30), der eine neueste Revision des ursprünglichen Datenstroms (36) darstellt, zugeordnet wird, ein mit der niedrigsten Nummer versehenes Transaktionselement (28) in der Transaktionskette (38) einem Deltastrom (34), der eine erste Revision des ursprünglichen Datenstroms (36) darstellt, zugeordnet ist, und mit aufeinanderfolgenden Nummern versehene Transaktionselemente (28, 26, 24) in der Transaktionskette (38) sequentiellen Revisionen des ursprünglichen Datenstroms (36) zugeordnet sind;

wobei im Schritt a) die Suchanforderung (102) in der Transaktionskette (38) eingeleitet wird;

wobei im Schritt b) die Datenbytes durch das mit der höchsten Nummer versehene Transaktionselement bereitgestellt werden.

3. Ein Verfahren gemäß Anspruch 2, das ferner den Schritt eines Lesens des ursprünglichen Datenstroms (36) direkt von einem sequentiellen Medium aufweist.

4. Ein Verfahren zum Aufbauen eines negativen Deltastroms (58) während eines Zusammenfügens eines ursprünglichen Datenstroms (36) mit einem Deltastrom (34) in einem programmierbaren Computer, wobei das Verfahren folgende Schritte aufweist:

a) Einleiten einer Suchanforderung (102), in einem aktuellen Übereinstimmungs- und/oder Datendeltarahmen des Deltastroms (34), nach einer Anzahl von Datenbytes, die an einen aktualisierten Datenstrom (52) zu übertragen sind;

b) falls der aktuelle Deltarahmen des Deltastroms (34) leer ist, Laden (120) eines nächsten Deltarahmens von dem Deltastrom (34) als den aktuellen Deltarahmen;

c) Überwachen (172) einer dem Deltastrom (34) zugeordneten Ursprünglicher-Datenstrom-Position;

d) nach dem Laden (120) eines nächsten Deltarahmens, der ein Übereinstimmungsrahmen ist,

i) Berechnen (172) eines Vorheriger-Strom- Verzögerungszählwerts als den Unterschied zwischen der Quellenübereinstimmungsposition des Übereinstimmungsrahmens und der Ursprünglicher-Datenstrom-Position des Deltastroms;

ii) Übertragen (194, 202) einer Anzahl von Bytes, die gleich dem Vorheriger-Strom- Verzögerungszählwert ist, von dem ursprünglichen Datenstrom (36) an den negativen Deltastrom (58) in Form eines Datenrahmens;

iii) Erzeugen (176) einer Umkehrung des Übereinstimmungsrahmens;

iv) Aufzeichnen (178) des umgekehrten Übereinstimmungsrahmens in dem negativen Deltastrom (58); und

v) Inkrementieren (188, 208) der dem Deltastrom (34) zugeordneten Ursprünglicher-Datenstrom- Position um eine Zahl, die gleich dem Vorheriger-Strom-Verzögerungszählwert ist;

e) falls der Deltastrom (34) in der Lage ist, Datenbytes von einem aktuellen Rahmen, der ein Datenrahmen ist, zu liefern, Erfüllen (110) der Suchanforderung (102) mit Datenbytes, die von dem aktuellen Rahmen bereitgestellt werden;

f) falls der Deltastrom nicht in der Lage ist, die Suchanforderung (102) zu erfüllen (110), Erfüllen (112) der Suchanforderung (102) mit Datenbytes, die durch den ursprünglichen Datenstrom bereitgestellt werden;

g) Inkrementieren der dem Deltastrom (34) zugeordneten Ursprünglicher-Datenstrom-Position um die Anzahl von Datenbytes, die durch den ursprünglichen Datenstrom dem aktualisierten Datenstrom (52) bereitgestellt werden; und

h) Wiederholen der Schritte a) - g), bis eine Suchanforderung (102) nicht erfüllt (110, 112) werden kann und der aktualisierte Datenstrom (52) vollständig (106) ist.

5. Ein Verfahren zum Zusammenfügen einer sequentiellen Mehrzahl von Deltaströmen (30, 32, 34), um einen kompilierten Deltastrom (294) in einem programmierbaren Computer zu erzeugen, wobei das Verfahren folgende Schritte aufweist:

a) Einleiten einer Suchanforderung (298), in der sequentiellen Mehrzahl von Deltaströmen (30, 32, 34), nach einem Datenrahmen, der an den kompilierten Deltastrom (294) zu übertragen ist;

b) Erfüllen (306) der Suchanforderung (298) mit einem Datenrahmen, der durch den letzten Deltastrom in der sequentiellen Mehrzahl von Deltaströmen (30, 32, 34), der in der Lage ist, einen Datenrahmen zu liefern, bereitgestellt wird;

c) falls die sequentielle Mehrzahl von Deltaströmen (30, 32, 34) nicht in der Lage ist, die Suchanforderung (298) zu erfüllen (306), Aufbauen (140) eines Übereinstimmungsrahmens, der an den kompilierten Deltastrom (294) zu übertragen (308) ist; und

d) Wiederholen der Schritte a) - c), bis eine Suchanforderung (298) nicht erfüllt (306, 308) werden kann und der kompilierte Deltastrom (394) vollständig (302) ist.

6. Ein Verfahren gemäß Anspruch 5, das vor dem Schritt a) folgenden Schritt aufweist:

Aufbauen einer Kette (38) aus Transaktionselementen (24, 26, 28), die der sequentiellen Mehrzahl von Deltaströmen (30, 32, 34) entsprechen, wobei ein mit der höchsten Nummer versehenes Transaktionselement (24) in der Transaktionskette (38) einem Deltastrom (30), der eine neueste Revision eines ursprünglichen Datenstroms (36) darstellt, zugeordnet wird, ein mit der niedrigsten Nummer versehenes Transaktionselement (28) in der Transaktionskette (38) einem Deltastrom (34), der eine erste Revision des ursprünglichen Datenstroms (36) darstellt, zugeordnet ist, und mit aufeinanderfolgenden Nummern versehene Transaktionselemente (28, 26, 24) in der Transaktionskette (38) sequentiellen Revisionen des ursprünglichen Datenstroms (36) zugeordnet sind;

wobei im Schritt a) die Suchanforderung (298) in der Transaktionskette (38) eingeleitet wird;

wobei im Schritt b) der Datenrahmen durch das mit der höchsten Nummer versehene Transaktionselement in der Transaktionskette (38) bereitgestellt wird.

7. Ein Computer, der programmiert ist, um eine sequentielle Mehrzahl von Deltaströmen (30, 32, 34) in einem einzigen Durchlauf mit einem ursprünglichen Datenstrom (36) zusammenzufügen, um einen aktualisierten Datenstrom (52) zu erzeugen, wobei der Computer folgende Merkmale aufweist:

a) eine Transaktionskette (38), die eine Mehrzahl von sequenzierten Transaktionselementen (24, 26, 28) aufweist, wobei jedes Transaktionselement (24, 26, 28) eine Deltastromeingabe (42, 44, 46) aufweist, die einem der sequentiellen Mehrzahl von Deltaströmen (30, 32, 34) entspricht; und

b) einen Verbraucherprozeß (22), der mit einem hinteren Element (24) der Transaktionskette (38) verbunden ist und eine Eingabe (48) für den ursprünglichen Datenstrom (36) und eine Ausgabe (50) für den aktualisierten Datenstrom (52) aufweist.

8. Ein Computer, der programmiert ist, um eine sequentielle Mehrzahl von Deltaströmen (30, 32, 34) in einem einzigen Durchlauf zusammenzufügen, um einen kompilierten Deltastrom (294) zu erzeugen, wobei der Computer folgende Merkmale aufweist:

a) eine Transaktionskette (38), die eine Mehrzahl von sequenzierten Transaktionselementen (24, 26, 28) aufweist, wobei jedes Transaktionselement (24, 26, 28) eine Deltastromeingabe aufweist, die einem der sequentiellen Mehrzahl von Deltaströmen (30, 32, 34) entspricht; und

b) einen Compiler-Verbraucherprozeß (286), der mit einem hinteren Element (24) der Transaktionskette (38) verbunden ist und eine Ausgabe für den kompilierten Deltastrom (294) aufweist.

9. Ein physisches Speichermedium, das programmiert ist, um einen Computer bei einem Zusammenfügen einer sequentiellen Mehrzahl von Deltaströmen (30, 32, 34) mit einem ursprünglichen Datenstrom (36) in einem einzigen Durchlauf, um einen aktualisierten Datenstrom (52) zu erzeugen, zu steuern, wobei das Medium folgende Merkmale aufweist:

a) eine Einrichtung, um eine Transaktionskette (38) zu erzeugen, die eine Mehrzahl von sequenzierten Transaktionselementen (24, 26, 28) aufweist, wobei jedes Transaktionselement (24, 26, 28) eine Deltastromeingabe (42, 44, 46) aufweist, die einem der sequentiellen Mehrzahl von Deltaströmen (30, 32, 34) entspricht;

b) einen Verbraucherprozeß (22), der eine Eingabe (48) für den ursprünglichen Datenstrom (36) und eine Ausgabe (50) für den aktualisierten Datenstrom (52) aufweist; und

c) eine Einrichtung, um den Verbraucherprozeß (22) mit einem hinteren Element (24) der Transaktionskette (38) zu verbinden.

10. Ein physisches Speichermedium, das programmiert ist, um einen Computer bei einem Zusammenfügen einer sequentiellen Mehrzahl von Deltaströmen (30, 32, 34) in einem einzigen Durchlauf, um einen kompilierten Deltastrom (294) zu erzeugen, zu steuern, wobei das Medium folgende Merkmale aufweist:

a) eine Einrichtung, um eine Transaktionskette (38) zu erzeugen, die eine Mehrzahl von sequenzierten Transaktionselementen (24, 26, 28) aufweist, wobei jedes Transaktionselement (24, 26, 28) eine Deltastromeingabe aufweist, die einem der sequentiellen Mehrzahl von Deltaströmen (30, 32, 34) entspricht;

b) einen Compiler-Verbraucherprozeß (286), der eine Ausgabe für den kompilierten Deltastrom (294) aufweist; und

c) eine Einrichtung, um den Compiler-Verbraucherprozeß (286) mit einem hinteren Element (24) der Transaktionskette (38) zu verbinden.