DE10059006B4

DE10059006B4 - Verfahren und System zur sicheren Verwaltung von Dateien in nichtflüchtigen Speichern

Info

Publication number: DE10059006B4
Application number: DE10059006A
Authority: DE
Inventors: Torsten Teich; Martin Witzel
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1999-12-30
Filing date: 2000-11-28
Publication date: 2004-04-15
Anticipated expiration: 2020-11-29
Also published as: US20010007108A1; DE10059006A1

Abstract

Verfahren zur Sicherstellung der Konsistenz von Daten, die in verschiedenen Dateien in Datensätzen gespeichert sind, wobei diese Datensätze durch eine Transaktion geändert werden, wobei jede Änderung eines Datensatzes einer Datei zur Anlegung von neuen Datensätzen in den von der Transaktion betroffenen Dateien führt, wobei das Verfahren durch folgende Schritte gekennzeichnet ist:
a) Bestimmen einer von der Transaktion betroffenen Dateien als Primärdatei, wobei nur diese Datei Statusinformationen über den Erfolg der Durchführung der Transaktion enthält, wobei die Statusinformationen den Zustand „aktuell" oder „nicht aktuell" annehmen kann,
b) Setzen der Statusinformation „aktuell" in jedem neu angelegten Primärdatensatz der Primärdatei,
c) Prüfen, ob in der Primärdatei mehrere Primärdatensätze mit der Statusinformation „aktuell" enthalten sind,
d) Rücksetzen der Statusinformation des Primärdatensatzes der Primärdatei, der dem neu angelegten Primärdatensatzes vorhergeht auf „nicht aktuell" und Belassen der Statusinformation „aktuell" des neu angelegten Primärdatensatzes, wenn kein Abbruch der Schreiboperation in einem Datensatz der...

Description

BEREICH DER ERFINDUNG
Diese Erfindung bezieht sich im Allgemeinen auf Verbesserungen der Dateiverwaltung von Dateien in nichtflüchtigen Speichern und insbesondere auf die sichere Verwaltung von Dateien im nichtflüchtigen Speicherbereich von Chipkarten und anderen digitalen Geräten für den Fall unterbrochener Schreibzyklen.
HINTERGRUND DER ERFINDUNG
Chipkarten verbreiten sich immer mehr in unterschiedlichen Anwendungsbereichen, zum Beispiel als Telefonkarten, Bankkarten, Kreditkarten, IU-Karten, Versicherungskarten usw. Zusätzlich zu den ausgefeilteri Identifikations- und Berechtigungs-Mechanismen, die sie enthalten, werden Chipkarten häufig als Datenspeicherein.heiten benutzt. Bei typischen Prozessen und Operationen mit Chipkarten, zum Beispiel Zahlungsoperationen, Autorisierungsprozessen usw., müssen die auf der Chipkarte gespeicherten Daten geändert werden. Im Folgenden werden solche Prozesse und Operationen als "Transaktionen" bezeichnet.
Bei einer Vielzahl von Transaktionen, die mit einer Chipkarte ausgeführt werden, müssen Teile der in der Mikrosteuereinheit (microcontroller) der Chipkarte enthaltenen Software entweder vollständig oder gar nicht ausgeführt werden. Eine Folge von Operationen, die nicht geteilt werden kann (und die deshalb nur vollständig oder gar nicht ausgeführt werden kann), wird als atomare Operationsfolge bezeichnet. Atomare Operationsfolgen treten immer in EEPROM-Schreibroutinen auf. Atomare Folgen beruhen auf der Voraussetzung, dass in EEPROM-Schreibzyklen gewährleistet sein muss, dass die jeweiligen Daten nicht nur teilweise geschrieben werden. Das kann beispielsweise vorkommen, wenn der Nutzer der Chipkarte die Karte während des Schreibprozesses aus dem Endgerät (terminal) herausnimmt oder wenn der Strom ausfällt. Eine sichere Verwaltung der EEPROM-Schreibdaten ist besonders wichtig, wenn die Chipkarte als elektronisches Zahlungsmittel (e-cash) verwendet wird, da die Chipkarte eine zuverlässige Zahlungsvorrichtung für den Nutzer sein muss, und weil insbesondere bei Zahlungstransaktionen Daten, die in unterschiedlichen Dateien enthalten sind, gleichzeitig geändert werden müssen.
In diesen Fällen muss das Betriebssystem der Chipkarte sicherstellen, dass die Konsistenz aller Daten garantiert wird, wenn die Chipkarte nach einem unterbrochenen Schreibprozess wieder in Betrieb genommen wird.

Gegenwärtig enthalten Chipkarten in ihren EEPROMs Sicherungspuffer (backup buffer). Solche Puffer sind groß genug, um alle notwendigen und wichtigen Daten zu speichern, und enthalten ein Kennzeichen (flag), das den Status anzeigt. Das Kennzeichen kann entweder auf "Daten im Puffer gültig" oder auf "Daten im Puffer ungültig" gesetzt werden. Zusätzlich muss ein Zuordnungsspeicher für die Zieladresse und die tatsächliche Länge der Pufferdaten zur Verfügung stehen. Im Betriebsfall werden die Daten in der Zieladresse in den Puffer kopiert, zusammen mit ihrer physischen Adresse und Länge. Das Kennzeichen wird auf "Daten im Puffer gültig" gesetzt. In einem nächsten Schritt werden die neuen Daten an die gewünschte Adresse geschrieben, und das Kennzeichen wird auf "Daten im Puffer ungültig" gesetzt. Wenn das Betriebssystem vor ATR (Antwort zurückzusetzen) gestartet wird, wird das Kennzeichen geprüft. Falls es auf "Daten im Puffer gültig" gesetzt ist, werden die im Puffer enthaltenen Daten automatisch an die gleiche gespeicherte Adresse geschrieben.

Mit diesem Mechanismus wird gewährleistet, dass gültige Daten in der Datei enthalten sind, und im Fall einer Programmunterbrechung können die Daten im EEPROM der Chipkarte wiederhergestellt werden.

Die bekannte Methode der Verwendung eines Sicherungspuffers hat verschiedene Nachteile. Erstens muss der Puffer wenigstens so groß sein wie die zu puffernden Daten und auf der Chipkarte auf dem EEPROM reserviert werden. Da der Platz auf dem EEPROM teuer ist und auf der Karte in genügender Größe vorhanden sein muss, um alle für den Nutzer wichtigen Daten zu speichern, kann der Puffer nicht beliebig groß sein. Deshalb ist die Menge und die Größe der zu puffernden Daten beschränkt. Zweitens ist der Puffer einem ständigen Betrieb ausgesetzt und deshalb übermäßig beansprucht / belastet. Da die Zahl der Schreib- / Löschzyklen des EEPROM begrenzt ist, besteht das Risiko, dass Daten in diesem wichtigen Puffer höchstwahrscheinlich auf Grund des Verschleißes des, Speichers verfälscht werden. Drittens wird auf Grund des obligatorischen Schreibzugriffs auf den Puffer die Ausfuehrungszeit des Programms verlaengert. Unter unguenstigen Bedingungen kann der Zugriff dreimal laenger dauern als der direkte Schreibzugriff auf den EEPROM. Diese Erfindung ueberwindet auch diese Nachteile.

US 5682513 beschreibt ein System, bei dem zur Vorbeugung des Datenverlustes Daten asynchron auf einen zweiten Rechner uebertragen werden und von Host-Controllern bearbeitet werden. Dafuer werden auf dem Primaerrechner die Daten in einem Cache-Memory gehalten.

Demzufolge ist es eine primäre Aufgabe der vorliegenden Erfindung, die oben erwähnten Nachteile zu überwinden und ein einzigartiges Verfahren und System für die sichere Verwaltung von Daten bei Chipkarten-Anwendungen zur Verfügung zu stellen.

Diese und andere Aufgaben der vorliegenden Erfindung werden erreicht durch. Speichern der Daten in logischen Strukturen, d.h. in satzorientierten (record-oriented) Datenstrukturen. Jeder Satz enthält zusätzlich zum Dateninhalt ein Statusbyte. Das Statusbyte zeigt an, ob dieser Satz gegenwärtig gültig ist oder nicht (Primärattribut). Weiterhin enthält der Satz eine Folgenummer (Synchronisationsnummer), die verwendet wird, um die Verbindung zu den zu synchronisierenden Dateien herzustellen (Sekundärattribut). In der Menge der zu synchronisierenden Dateien wird eine Primärdatei definiert, deren aktueller Satz die gegenwärtig gültige Synchronisationsnummer enthält. Die andere(n) Datei(en) wird (werden) als Sekundärdatei en) bezeichnet.

Entsprechend der vorliegenden Erfindung wird ein Verfahren und ein System zur Datenverwaltung in einem Chipkarten-EEPROM bereitgestellt, das die Daten selbst für den Fall der Synchronisatiansnummer enthält. Die andere(n) Datei(en) wird (werden) als Sekundärdatei(en) bezeichnet.

Entsprechend der vorliegenden Erfindung wird ein Verfahren und ein System zur Datenverwaltung in einem Chipkarten-EEPROM bereitgestellt, das die Daten selbst für den Fall der Unterbrechung oder des Abbruchs einer Folge (zum Beispiel durch Stromausfall) sichert, ohne dass ein Puffer benötigt wird. Die Erfindung ermöglicht, dass zwei oder mehr Dateien der Chipkarte konsistent bleiben, wenn eine Unterbrechung auftritt, während die Dateien aktualisiert werden, indem die Informationen, die die Herstellung der Konsistenz betreffen, zusammen mit den Daten gespeichert werden. Dadurch wird die Datensicherheit selbst über Kommandofolgen hinweg gewährleistet. Die Erfindung umfasst ein spezielles Datenformat und einen Suchalgorithmus, um die gültigen Dateiinhalte zu bestimmen und Daten zu korrigieren, die auf Grund von Unterbrechungen oder Speicherfehlern unvollständig geschrieben wurden. Der Satzsuchalgorithmus macht eine spezielle Wiederherstellungsroutine für Dateninhalte nach einer unnötigen Unterbrechung verfügbar.

KURZE BESCHREIBUNG DER ZEICHNUNGEN

1 veranschaulicht die Struktur einer Datei entsprechend der vorliegenden Erfindung;

2 ist eine Veranschaulichung der Struktur der logischen Sätze, die entsprechend der vorliegenden Erfindung in einer Datei, so wie sie in 1 gezeigt wird, enthalten sind.

3a und 3b veranschaulichen einen sequentiellen Ablauf für eine beliebige Anzahl von Dateien 1 bis n entsprechend der vorliegenden Erfindung.

AUSFÜHRLICHE BESCHREIBUNG DER ERFINDUNG – ZWEI DATEIEN

Zuerst wird die Erfindung für den Fall von zwei von einer Transaktion betroffenen Dateien dargestellt. 1 zeigt die Struktur jeder Datei – Primärdatei und Sekundärdatei – entsprechend der Erfindung. 2 veranschaulicht die Struktur jedes Satzes. Entsprechend 1 besteht jede Datei aus einer Angabe der Anzahl der logischen Sätze, der Größe der logischen Sätze und einer fortlaufend nummerierten Vielzahl von logischen Sätzen. Jeder Satz besteht aus einer Angabe des Satzstatus, einer Synchronisationsnummer und dem Dateninhalt, so wie in 2 dargestellt.

Wenn die an einer Transaktion beteiligten Dateien aktualisiert werden, wird der folgende Algorithmus benutzt:

1. Bestimme den aktuellen aktiven logischen Satz und den (Arbeits-)Satz der zu schreibenden Schlüsseldatei.
2. Setze die Synchronisationsnummer des Arbeitssatzes der Schlüsseldatei auf die Synchronisationsnummer des aktiven Satzes und erhöhe die Synchronisationsnummer des aktuellen Satzes um 1.
3. Schreibe die neuen Daten der Schlüsseldatei in den Arbeitssatz.
4. Ändere den Satzstatus des Arbeitssatzes der Schlüsseldatei auf "aktiv".
5. ...
6. Führe eine vollständige Aktualisierung der Sekundärdatei durch, einschließlich der Definition neuer aktiver Sätze.
7. ...
8. Ändere den Satzstatus des alten aktiven Satzes der Schlüsseldatei auf "nicht aktiv".

Durch Anwendung dieses Algorithmus kann für die Primär- und die Sekundärdatei gewährleistet werden, dass neue Dateninhalte durch eine einzige (atomare) Schreiboperation in der Primärdatei (Schritt 8 im obigen Algorithmus) gültig werden und dass keine inkonsistenten Zwischenstufen der Dateninhalte auftreten. Schritt 5 und 7 im obigen Algorithmus sind wahlweise Schritte, die für zusätzliche, auf der Chipkarte auszuführende Schritte reserviert werden können und die nicht Teil der vorliegenden Erfindung sind. Die einzige Anforderung hierfür besteht darin, dass die Bestimmung des aktiven logischen Satzes und des Arbeitssatzes entsprechend dem folgenden Satzsuchalgorithmus für die Schlüsseldatei ausgeführt wird:

1. Beginne mit dem ersten physischen Satz und suche nach dem ersten Satz, dessen Status "aktiv" ist.
2. Falls der erste physische Satz und der letzte physische Satz der Datei als "aktiv" gekennzeichnet sind, ist der letzte physische Satz der aktive Satz.
3. Wenn kein Satz gefunden wird, der als aktiv gekennzeichnet ist, setze den ersten physischen Satz auf "aktiv".
4. Definiere den physischen Satz, der nach dem aktiven Satz folgt, als Arbeitssatz.
5. Falls der aktive Satz der letzte physische Satz der Datei ist, wird der erste physische Satz der Datei der Arbeitssatz.

Der Satzsuchalgorithmus für die Sekundärdatei arbeitet wie folgt:

1. Beginne mit dem ersten physischen Satz und suche nach dem ersten Satz, dessen Status "aktiv" ist.
2. Falls der erste physische Satz und der letzte physische Satz der Datei als "aktiv" gekennzeichnet sind, ist der letzte physische Satz der aktive Satz.
3. Wenn kein Satz gefunden wird, der als aktiv gekennzeichnet ist, setze den ersten physischen Satz auf "aktiv".
4. Vergleiche die Synchronisationsnummer des festgestellten aktiven Satzes mit der Synchronisationsnummer des aktiven Satzes der Primärdatei.
5. Wenn der Versuch fehlschlägt, markiere den Satz als "aktiv", dessen Synchronisationsnummer der Synchronisationsnummer des aktiven Satzes der Primärdatei entspricht.
6. Definiere den physischen Satz, der nach dem aktiven Satz folgt, als Arbeitssatz.
7. Falls der aktive Satz der letzte physische Satz der Datei ist, wird der erste physische Satz der Datei der Arbeitssatz.

AUSFÜHRLICHE BESCHREIBUNG DER ERFINDUNG – BELIEBIGE ANZAHL VON DATEIEN

Das oben beschriebene Verfahren kann ohne Änderungen der Algorithmen auf eine beliebige Anzahl von Dateien erweitert werden. In diesem Fall werden alle weiteren Dateien als Sekundärdateien klassifiziert. Nachfolgend wird das Verfahren entsprechend der vorliegenden Erfindung unter Bezugnahme auf

3a und 3b für eine beliebige Anzahl von Dateien erklärt, wobei ein Satz in einer Datei die folgende Struktur besitzt:

Das Kennzeichen. gibt an, ob ein Satz aktiv ("A") oder inaktiv ("I") ist. Ein Satz kann das "A"-Kennzeichen gesetzt haben, aber wird noch nicht. als gültig angesehen: wenn das Ptr2-Feld nicht auf den Beginn des Satzes zeigt, ist der Satz noch Teil einer Kette zu Sätzen. in anderen Dateien und noch im Aufbau begriffen'. Nur wenn Ptr2 auf den Anfang seines eigenen Satzes zeigt, kann mit Sicherheit gesagt werden, dass die Kette aufgelöst wurde und alle Dateien synchronisiert sind. Ein Satz mit dieser Bedingung und mit einem auf 'aktiv' gesetzten Kennzeichen könnte als 'voll aktiv' bezeichnet werden.

Die Dateien sind wiederum zyklische Dateien, eine Anordnung, die oft als Ringpuffer beschrieben wird. Sie sind satzorientiert, mit anderen Worten, es gibt, vom Standpunkt des Betriebssystems aus gesehen, immer einen 'aktuellen Satz'. Der aktuelle Satz muss nicht der gleiche sein wie der 'voll aktive' Satz.

Die nachstehende Folge von Ereignissen beschreibt, wie eine beliebige Anzahl von Dateien aktualisiert werden kann und gleichzeitig sichergestellt wird, dass entweder die aktuellen (alten) Informationen in allen Dateien zugänglich bleiben oder garantiert wird, dass die neuen Informationen in allen Dateien existieren. Die Anzahl von Dateien kann wahrscheinlich verringert und das Schema stark vereinfacht werden, wenn wir nur mit einer wohldefinierten Menge von Dateien arbeiten, die sich niemals ändert.

a. Anhängen oder Aktualisieren des Datenfeldes eines Satzes in der ersten Datei: a1 Anhängen eines neuen Satzes in Datei 1 (die Primärdatei) und Kopieren der Daten aus dem aktuellen Satz in diesen neuen Satz. Modifikation der Daten, so wie gefordert. Der angehängte Satz wird der aktuelle Satz (vom Standpunkt des Operationssystems aus gesehen). Der vorhergehende Satz bleibt 'voll aktiv' (vom Standpunkt des sicheren Aktualisierungsmechanismus aus gesehen). [erstes Schreiben des Ptr2] Ein Stromausfall zu diesem Zeitpunkt lässt den vorhergehenden Satz noch 'voll aktiv'. Ptr2 im aktuellen Satz zeigt auf diesen Satz, weil er in Schritt (a1) aus dem vorhergehenden Satz in diese Datei kopiert wurde, wo er auf den Beginn des gleichen vorhergehenden Satzes zeigt. a2 Der neue (laufende) Satz wird als 'inaktiv' gekennzeichnet [erstes Schreiben der Kennzeichnung]. Schritt a2 kann auch zusammen mit Schritt a1 in einer Schreiboperation erreicht werden. a3 Ptr1 wird auf einen Wert gesetzt, der das Ende einer verketteten Liste anzeigt (keine Verbindung zu einer nachfolgenden Datei) [erstes Schreiben des Ptr1]. a4 Ptr3 wird auf einen Wert gesetzt, der das Ende einer verketteten Liste anzeigt (die erste Datei hat keine Verbindung zu einer vorhergehenden Datei) [erstes Schreiben des Ptr3]. Ein Stromausfall während dieses Prozesses findet den vorhergehenden Satz noch wie zuvor: voll aktiv, keine Änderungen. Irgendwelche Veränderungen des neuen (aktuellen) Satzes in Datei 1 bleiben deshalb unsichtbar und werden ausgeschaltet.
b. Anhängen oder Aktualisieren des Datenfeldes in der zweiten und in nachfolgenden Dateien: b1 Anhängen eines neuen Satzes in dieser zweiten, dritten, usw. Datei und Kopieren der Daten aus dem aktuellen Satz in diesen neuen Satz. Der angehängte Satz wird der aktuelle Satz. Modifikation der Daten, so wie gefordert. Der vorhergehende Satz bleibt 'voll aktiv' [erstes Schreiben des Ptr2]. Ein Stromausfall zu diesem Zeitpunkt lässt den vorhergehenden Satz noch 'voll aktiv'. Ptr2 zeigt auf diesen Satz, weil er in Schritt (b1) aus dem vorhergehenden Satz in diese Datei kopiert wurde, wo er auch auf den Anfang dieses Satzes zeigt. b2 Der neue (laufende) Satz wird als 'inaktiv' gekennzeichnet [erstes Schreiben der Kennzeichnung]. Schritt b2 kann auch zusammen mit Schritt b1 in einer Schreiboperation erreicht werden. b3 Ptr1 wird auf einen Wert gesetzt, der das Ende einer verketteten Liste anzeigt (keine Verbindung zu einer nachfolgenden Datei) [erstes Schreiben des Ptr1]. b4 Ptr3 wird so gesetzt, dass er auf den neuen (laufenden) Satz in der vorhergehenden Datei zeigt . Dies stellt eine Rückwärtsverbindung zwischen den Dateien her [erstes Schreiben von Ptr3]. Wir sind jetzt fertig mit dem neuen (laufenden) Satz in dieser Datei 2, 3, usw. Datei 1 und Datei 2 können noch auf ihre vorhergehenden Sätze zurückgehen, die 'voll aktiv' sind. Ptr2 im laufenden Satz sollte ein automatisches internes Zurückgehen (backtracking) leicht möglich machen oder einfach die Optionen in dem Befehl 'Lies Satz' (Read Record command) verwenden, um den vorhergehenden Satz zu adressieren. b5 Ptr1 in dem neuen (laufenden) Satz in der vorhergehenden Datei wird so gesetzt, dass er auf den neuen Satz in dieser Datei zeigt. Dies stellt eine Vorwärtsverbindung von der vorhergehenden Datei in der Kette zu dieser Datei her [zweites Schreiben des Ptr1]. b6 Die Kennzeichnung in dem neuen Satz der vorhergehenden Datei wird auf 'aktiv' gesetzt [zweites Schreiben der Kennzeichnung].
Ptr2 des neuen Satzes in der vorhergehenden Datei zeigt jedoch noch auf den vorhergehenden Satz in der vorhergehenden Datei. Deshalb kann der neue Satz noch nicht. 'voll aktiv' werden.
Ein Stromausfall während dieses Prozesses findet die vorhergehenden Sätze noch wie zuvor in der (den) Datei(en): voll aktiv, keine Änderungen. Irgendwelche Änderungen der neuen Sätze in diesen Dateien 2, 3 usw. bleiben unsichtbar und werden verworfen.
c. ... und so weiter mit beliebigen weiteren Dateien, bis wir alle Daten in allen Dateien, die in synchronisiertem Zustand gehalten werden müssen, angehängt oder aktualisiert haben. Es gibt einige abschließende Aktionen, die nur beim Anhängen oder Aktualisieren der (letzten) Datei auftreten. c1 Setze das Kennzeichenfeld des letzten angehängten (laufenden) Satzes auf 'aktiv' [zweites Schreiben, das erste war 'inaktiv' in Schritt a1 oder b1]. Wir können dieses zweite Schreiben einsparen, wenn wir bereits wissen, dass dies die letzte Datei ist, wenn wir den neuen Satz anhängen, und seinen Inhalt modifizieren, wenn wir ihn vom vorhergehenden Satz kopieren. Ein Stromausfall zu diesem Zeitpunkt lässt eine unvollständige Kette zurück. Eine unvollständige Kette (eine, in der der letzte Satz in der Kette nicht als 'aktiv' markiert ist UND Ptr2 nicht auf den gleichen Satz zeigt) wird vollständig verworfen, und wir gehen zu den 'voll aktiven' (vorhergehenden) Sätzen in allen Dateien zurück. c2 Setze Ptr2 des neuen (aktuellen) Satzes so, dass er auf den Anfang des aktuellen Satzes zeigt . Dieses einmalige Schreiben macht den neuen Satz in der letzten Datei 'voll aktiv' und ermöglicht die Wiederherstellung. Jetzt haben wir den vorhergehenden Satz in der letzten Datei, er ist 'voll aktiv', ebenso den aktuellen Satz, der auch 'voll aktiv' ist. Ein Stromausfall nach dieser einfachen Schreiboperation hat keine nachteilige Auswirkung, weil wir jetzt alles wiederherstellen können.

Wiederherstellung

Wir können einen Stromausfall nach Schritt (c1) auf zwei Arten reparieren: wir können entweder wieder von vorn anfangen, alle Dateien zu aktualisieren; alle vorhergehenden Sätze enthalten noch die alten Informationen, und ein neuer Versuch, die Dateien synchron zu aktualisieren, kann jetzt ebensogut erfolgreich sein. Wenn wir neue Sätze an die Dateien anhängen, kopieren wir die Ptr2-Felder auch in die neuen Sätze, was uns zu einem 'voll aktiven' Satz in jeder Datei zurückführt.

Alternativ hierzu ist es möglich, nach vorn zu gehen und jetzt alle neuen (laufenden) Sätze in der Kette voll aktiv zu machen, was viel bequemer ist:
Prüfe die Notwendigkeit der Wiederherstellung nach einem Stromausfall:

d. Prüfe die Primärdatei 1, ob es einen aktuellen Satz gibt, bei dem das Kennzeichen 'aktiv' gesetzt ist UND Ptr2 nicht auf das Kennzeichenfeld des gleichen Satzes zeigt. Wenn wir einen solchen Satz in Datei 1 finden, muss er in Schritt (a) oben hinzugefügt worden sein. Wenn kein solcher Satz vorhanden ist, müssen wir nichts wiederherstellen nach einem Stromausfall.

Wiederherstellung, die verkettete Liste wurde erfolgreich aufgebaut

Wir starten am Ende der Kette, um die Sätze vo11 aktiv zu machen. Die Kette wird mit jeder erfolgreichen Aktivierung eines neuem Satzes kürzer, bis Ptr2 im neuen (laufenden) Satz in Datei 1 auf das Kennzeichenfeld des gleichen Satzes zeigt und dann auch 'voll aktiv' ist.

Wir starten mit dem jetzt 'voll aktiven' Satz, der in Datei 1 gefunden wurde, folgen der Kette längs der Ptr1-Verbindungen, bis Ptr1 das Ende der Kette anzeigt, wo das Kennzeichenfeld als 'aktiv, letztes in der Kette' markiert ist.

d1 Wenn der neue (laufende) Satz in der letzten Datei der verketteten Liste 'voll aktiv' ist, durchsuche die Datei nach einem anderen voll aktiven Satz, und, falls einer gefunden wird, setze dort das Kennzeichen auf 'inaktiv' [drittes Schreiben des Kennzeichens]. Fahre mit Schritt (d4) fort und löse die Verbindung mit der Datei. Dies war die letzte Datei in der ursprünglichen Kette, da sie zwei 'voll aktive' Sätze enthält, oder wir müssen einen Ausfall während der Wiederherstellung zwischen den Schritten (d3) und (d4) gehabt haben, nachdem diese Datei vollständig verarbeitet wurde, aber noch mit der vorhergehenden Datei verkettet war.
d2 Wenn der neue (aktuelle) Satz 'aktiv' ist, aber Ptr2 nicht auf den Anfang seines eigenen Satzes zeigt, folge Ptr2 zum vorhergehenden Satz in der letzten Datei. Prüfe, ob der vorhergehende Satz 'voll aktiv' ist; falls ja, setze das Kennzeichen dort auf inaktiv [drittes Schreiben des Kennzeichens]. Wenn der Strom nach diesem Schritt ausfällt, erreichen wir wieder das Ende der Kette, bemerken aber, dass wir mit dem vorhergehenden Satz nichts weiter tun müssen.
d3 Modifiziere Ptr2 in dem neuen (aktuellen) Satz in der letzten Datei in der Kette so, dass er auf den Anfang des gleichen Satzes zeigt [zweites Schreiben des Ptr2]. Dies macht den neuen (aktuellen) Satz 'voll aktiv'. Ein Stromausfall zu diesem Zeitpunkt lässt den neuen (aktuellen) Satz in der letzten Datei als 'voll aktiv' gekennzeichnet. Wenn die Wiederherstellung erneut gestartet wird, läuft sie zum Schritt (d1) und überspringt (d2, d3, d4).
d4 Löse die Verbindung zur gegenwärtig letzten Datei: setze Ptr1 in der vorhergehenden Datei (Ptr3 bringt uns dorthin) auf einen Wert, der das Ende der verketteten Liste anzeigt. Bei einem Stromausfall zu diesem Zeitpunkt wird die verkettete Liste um eine Datei verkürzt. Der Wiederherstellungsprozess kann einfach erneut beginnen, stellt fest, dass die vorhergehende Datei jetzt die letzte Datei ist und geht zum Schritt (d2).
d5 Wenn der Strom nicht ausfällt und wir fortfahren können: gehe rückwärts längs der durch Ptr3 verketteten Liste zur vorhergehenden Datei und wiederhole die Schritte (d1, d2, d4, d5), bis Ptr3 signalisiert, dass wir uns am Anfang der Kette in Datei 1 befinden.

Wiederherstellung, die verkettete Liste wurde nicht erfolgreich aufgebaut

e1 Wenn der neue (letzte) Satz in der letzten Datei in der verketteten Liste aktiv ist, aber Ptr2 nicht auf den Anfang des Satzes zeigt, können wir nach (a1), (b1) oder (c1) unterbrochen worden sein. Setze die Kennzeichnung auf 'inaktiv'. Ein Stromausfall zu diesem Zeitpunkt lässt die Zeiger intakt (Ptr2 wird benötigt). Wir können wieder in die Wiederherstellungsroutine eintreten und zu (e2) gelangen.
e2 Wenn der neue (aktuelle) Satz in der letzten Datei in der verketteten Liste inaktiv ist und Ptr2 nicht auf den Anfang des Satzes zeigt, wurden wir nach den Schritten (a2), (b2) oder (e1) unterbrochen. Ansonsten gehe zu Schritt (e5). Folge jetzt Ptr2 zum vorhergehenden Satz in dieser Datei. Wir sind im alten (vorhergehenden) Satz und gehen zu seinen alten Daten zurück. Setze Ptr1 so, dass er auf den neuen (aktuellen) Satz zeigt. Wir müssen ihn jetzt finden können, Beachte: Ptr1 ist nicht länger Teil einer Kette im alten Satz und kann wieder verwendet werden. Ein Stromausfall zu diesem Zeitpunkt lässt uns erneut starten, und wir gehen wieder zu Schritt (e2) zurück.
e3 Setze die Kennzeichnung im alten Satz auf 'aktiv, wiederhergestellt', um ihn vom voll aktiven letzten Satz in einer Kette zu unterscheiden, der in den Schritten d1 ... d5 beschrieben wird.
Ein Stromausfall zu diesem Zeitpunkt lässt uns die Wiederherstellung erneut starten, und wir kehren wieder zu (e2) zurück.
e4 Mache diesen alten (vorherigen) Satz in der letzten Datei zum aktuellen Satz, vom Standpunkt des Betriebssystems aus. Ein Stromausfall zu diesem Zeitpunkt lässt die verkettete Liste mit einem aktuellen Satz in der letzten Datei zurück, der 'aktiv, wiederhergestellt' ist, und Ptr2 zeigt auf den Anfang des Satzes. Diese Datei wurde erfolgreich wiederhergestellt, aber wir haben diese letzte Datei noch nicht aus der Kette herausgelöst. Ein Stromausfall zu diesem Zeitpunkt bedeutet, dass wir wieder in (e2) eintreten und bis nach (e5) durchlaufen.
e5 Wenn der alte (aktuelle) Satz in der letzten Datei in der verketteten Liste 'aktiv, wiederhergestellt' ist und Ptr2 auf den Anfang dieses Satzes zeigt, wird diese aktuell letzte Datei aus der Kette herausgelöst. Folge Ptr1 im aktuellen Satz der letzten Datei, um den jetzt ehemaligen "neuen" Satz zu finden, der einen gültigen Ptr3 mit einer rückwärts gerichteten Dateiverkettung enthält. Setze Ptr1 in der vorhergehenden Datei auf einen Wert, der das Ende der verketteten Liste anzeigt. Die vorhergehende Datei ist jetzt die 'letzte Datei'. Fahre mit Schritt (e1) fort, bis Ptr1 anzeigt, dass wir am Anfang der verketteten Liste, Datei 1, sind.

Dieses Verfahren arbeitet genauso wie das, das zwei Dateien einschließt, unabhängig von verschiedenen Kriterien:

– Es ist unwichtig, wieviele verschiedene Dateien betroffen sind und synchronisiert gehalten werden müssen.
– Es ist unwichtig, in welcher Folge der Programmierer die zweite, dritte usw. Datei verwendet, d.h., wie eine spezifizierte Ablauffolge die Ordnung definiert, in der die Parameter aktualisiert werden.
– Alles, was für die Wiederherstellung benötigt wird, ist das Wissen, welche Datei in einer atomaren Folge zuerst aktualisiert wird. Markiere eine Datei als Datei 1, wenn es eine Datei gibt, bei der die 'aktive' Kennzeichnung gesetzt ist, wobei Ptr2 nicht auf den Anfang des gleichen Satzes zeigt. Wenn es keinen solchen Satz gibt, müssen wir keine Wiederherstellung durchführen.
– Das Verfahren schreibt höchstens dreimal an die gleichen Adressen (Kennzeichnung).

Das Folgende sind kommentierte Ausschnitte aus einem Beispiel eines Computerprogramms, das das Verfahren entsprechend der vorliegenden Erfindung für eine Kauffolge implementiert. Wenn es auf einem Computer läuft, führt ein solches Computerprogramm die Schritte eines Verfahrens entsprechend der vorliegenden Erfindung aus.

In dieser Ausführungsform der Erfindung werden die folgenden Abkürzungen verwendet: SAM (Modul für den sicheren Zugriff (Secure Access Module)), PSAM (Modul für den sicheren Zugriff beim Kauf (Purchase Secure Access Module) , erteilt Berechtigungen für Chipkarte, wenn Geld abgebucht wird, speichert akkumulierte. Kaufbeträge), LSRM (Modul für sicheren Zugriff beim Aufbuchen von Geld (Load Secure Access Module), erteilt Berechtigung für eine Chipkarte, wenn Geld auf die Karte aufgebucht wird, speichert akkumulierte aufgebuchte Beträge), PSALM (Kombination von PSAM und LSAM), HDR (Kopfsatz (Header)).

1. Atomare Ablauffolge – Initialisiere PSAM

Arbeite mit der Datei EF_PLOG:

1. Suche vom Anfang der Datei an, bis der erste aktuelle Satz (mit 01 als aktiv markiert) gefunden wird.
2. Markiere den nachfolgenden Satz mit 00. Dies wird unser Arbeitssatz, aber er bleibt inaktiv.
3. Kopiere alle anderen Datenfelder aus dem ersten gefundenen Satz in den Arbeitssatz.

Benutze jetzt den Arbeitssatz in EF_LOG:
Aktualisiere die Felder TRT, MTOT, NT, NIT, NC, NCR in diesem Satz so wie gefordert. Diese Satzaktualisierungsoperation wird im Betriebssystem der Chipkarte behandelt.

Der aktualisierte Satz in EF PLOG wurde noch nicht aktiviert! Das NIT-Inkrement in EF_TM kommt hier später in Schritt 1.

Wenn der Strom vorher oder zu diesem Zeitpunkt ausfällt, dann gehen wir zurück zu dem aktuellen aktiven Satz in EF PLOG und behalten die alten Informationen, die noch in Ordnung sind. Der Zustand ist auch der des alten Satzes. Der oben beschriebene Prozess kann deshalb wieder initialisiert werden.

Wenn alles gut gegangen ist, verfahre in EF_TM(x) auf ähnliche Weise.

4. Suche vom Anfang der Datei, bis der erste aktuelle Satz (mit 01 als aktiv markiert) gefunden wird.
5. Markiere den nachfolgenden Satz mit 00. Dies wird unser Arbeitssatz, aber er bleibt inaktiv.

Benutze jetzt den inaktiven Arbeitssatz in EF_TM(x).

Kopiere das bereits inkrementierte Feld NIT aus der Journal-Datei. EF_TM(NCR)[(1st found curr) +1] = '0'

Die aktuellen Zähler NIT und NT werden jetzt inkrementiert, aber der Satz ist noch inaktiv.

Wenn der Strom vor oder zu diesem Zeitpunkt ausfällt, gehen wir zu dem aktuell aktiven Satz EF_TM mit den alten Informationen zurück. Das ist noch in Ordnung, weil wir auch zu dem alten Satz EF_PLOG mit dem alten TRT-Zustand zurückgehen. Nachdem jedoch EF_PLOG aktiviert ist (was unten ausgeführt wird), sind wir gezwungen, auch EF_TM zu aktivieren.

Hinweis: Wenn wir den EF_TM-Arbeitssatz nicht hier aktivieren, schlägt die if-Anweisung in Complete Purchase (Schließeden Kauf ab) fehl. Nur zur Bezugnahme: so sieht es aus, wenn wir den EF_TM-Satz genau hier aktivieren: Arbeite mit der Datei EF_TM(x):

Wenn der Strom hier ausfällt, haben wir zwei aktive Sätze in EF_TM, finden aber hoffentlich den gleichen ersten aktiven (alten) Satz wie zuvor. Betrachte den Spezialfall des Umlaufens in der zyklischen Datei! Dies bedeutet, dass wir noch zu den alten Daten zurückgehen. OK.

Jetzt haben wir einen aktiven Satz in EF_TM mit dem korrekten NIT, der mit EF_PLOG übereinstimmt. Wenn der Strom hier ausfällt, zeigt der (alte) aktive Satz in EF_PLOG an, dass wir noch in dem Zustand PurCompletedE oder PurAbortCompletedE sind: wir wiederholen den Befehl "Initialisiere PSAM für den Kauf" (initialize PSAM for Purchase) mit den obigen Schritten und starten neue Sätze in EF_PLOG und in EF_TM.

Der noch inaktive Satz in EF_PLOG und der aktive Satz in EF_TM sind jetzt synchronisiert.

Wenn alles gut ging, dann machen wir den neuen Satz in EF PLOG zum aktuellen Satz (nicht ohne das Gleiche mit EF_TM zu tun ...).

Wenn der Strom jetzt ausfällt, haben wir zwei aktuelle = aktive Sätze. Wir suchen immer nur nach dem ersten, d.h., wir hoffen, den alten zu finden. Betrachte die Umlaufeffekte in einer zyklischen Datei. Wir gehen zurück und verlieren die Informationen in dem neuen Satz. Das ist noch in Ordnung.

Wenn der Strom jetzt ausfällt, finden wir einen neuen aktiven Satz in EF-PLOG mit dem TRT-Zustand = PurInitializedE und den inkrementierten Journal-Werten von NT, NIT und auch einen aktiven neuen Satz in EF_TM mit inkrementiertem NIT-Zähler.

Jetzt können wir nicht mehr zu der alten Information in EF_PLOG zurückkehren. Wir sind jetzt gezwungen, den Kauf entweder abzuschließen oder abzubrechen.

2. Atomare Ablauffolge – PSAM für den KauF gutschreiben

Dies ist ein anderer Zeitpunkt, zu dem die PSAM-Datei aktualisiert wird. Dieser Befehl kann wiederholt werden. Starte für jede Ausführung einen neuen Satz in EF_PLOG. Wir treten in den Befehl mit synchronisierten EF_PLOG- und EF TM-Werten ein.

Arbeite mit der Datei EF_LOG

1. Suche vom Anfang der Datei an, bis der erste aktuelle Satz (mit 01 als aktiv markiert) gefunden wird.
2. Markiere den folgenden Satz mit 00. Dies wird unser Arbeitssatz, aber er bleibt inaktiv.
3. Kopiere alle anderen Datenfelder aus dem ersten gefundenen Satz in den Arbeitssatz.

Wenn der Strom hier ausfällt, verlieren wir den Kaufbetrag und bleiben im vorhergehenden Zustand: PurInitializedE, wenn dies der erste Befehl Geldbetrag gutschreiben (CreditPurchase) war, PurchasingE, wenn dies ein Inkrementierungsbefehl war. Im Fall 1 müssen wir mit Abort Purchase (Abbrechen des Kaufes) fortsetzen, im Fall 2 mit Complete Purchase (Vollenden des Kaufs).

Arbeite mit der Datei EF_TM(x)(ordne einen neuen Arbeitssatz zu)

Wenn der Strom jetzt ausfällt, sind der Betrag TM und NIT im aktiven Satz in EF_TM mit dem aktiven Satz in EF PLOG synchronisiert, aber TM enthält nicht den letzten Kaufbetrag, nur der inaktive Satz widerspiegelt das. Wir könnten entweder den EF_TM-Satz hier aktivieren – dann haben wir jedesmal MPDA zu addieren. Oder wir überlassen die Aktivierung dem folgenden Befehl "Complete Purchase" (Vollende den Kauf) – dann müssen wir hier MTOT addieren.

Es gibt einen aktuellen inaktiven Satz in EF_LOG im Zustand PurchasingE mit aktualisierten MTOT- und BAL_IEP-Feldern. Aktiviere ihn jetzt.

3. Atomare Ablauffolge – Vollende den Kauf

Dies ist der letzte Schritt, in dem die noch ODER-verknüpften Dateiinhalte von EF_PLOG und EF_TM synchronisiert werden müssen. Der Befehl benutzt zur Arbeit einen neuen Satz in EF_PLOG. Der TRT-Zustand im neuen Satz in EF_PLOG muss auf PurCompletedE gesetzt werden. Prüfe die Werte in dem noch inaktiven neuen Satz in EF_TM(x) und aktiviere ihn.

Arbeite mit der Datei EF PLOG:

1. Setze den Endzustand im Arbeitssatz von EF PLOG. Dieser Satz ist noch inaktiv.
2. Wenn der NIT in EF_PLOG der gleiche ist wie der Wert in dem noch inaktiven Arbeitssatz in EF_TM(x), aktualisiere die TM- und NIT-Werte im Arbeitssatz. Ansonsten überspringe diesen Schritt. Gehe zurück.
3. Wenn der NIT in EF_PLOG der gleiche ist wie der Wert in dem noch inaktiven Arbeitssatz in EF_TM(x), aktiviere den Arbeitssatz in EF_TM(x). Ansonsten überspringe diesen Schritt. Gehe zurück.

Wenn der Strom ausfällt, gehen wir zurück zu dem jetzt aktiven neuen Satz in EF_PLOG mit dem Zustand PurchasingE und inkrementiertem NIT und dem noch aktiven alten Satz in EF_TM mit nichtinkrementiertem NIT.

Anmerkung: Das NIT in den zwei aktuell aktiven Sätzen in EF_PLOG und EF_TM(x) muss durch einen früheren Befehl "Initialize PSAM for Purchase" (Initialisiere PSAM für den Kauf) synchronisiert sein. Nur TM in EF_TM muss noch aktualisiert werden.

Arbeite mit der Datei EF TM(x):

Wenn der Strom hier ausfällt, haben wir zwei aktive Sätze, finden aber hoffentlich den gleichen ersten aktiven (alten) Satz wie zuvor. Betrachte den Spezialfall des Umlaufens in der zyklischen Datei! Dies bedeutet, dass wir noch zu den alten Daten zurückgehen. Mit diesen Voraussetzungen stellt der {HDR} sicher, dass der zweite aktive Satz wieder erst deaktiviert wird, wenn wir Complete Purchase ein weiteres Ma1 ausführen.

Jetzt haben wir einen aktiven Satz in EF_TM mit dem korrekten TM und ein NIT, das mit EF_PLOG übereinstimmt. Wenn der Strom hier ausfällt, zeigt der (alte) aktive Satz in EF_PLOG an, dass wir noch im Zustand PurchasingE sind; wir wiederholen den Befehl "Complete Purchase" mit den obigen Schritten und starten einen neuen Satz in EF_TM.

Wenn der Strom jetzt ausfällt, haben wir zwei aktuelle = aktive Sätze. Wir suchen immer nur den ersten, d.h., wir finden den alten. Wir gehen zurück und verlieren die TRT-Zustandsinformation = PurchasingE im neuen Satz. Dies ist noch in Ordnung, wiederhole nur den Befehl.

Wenn der Strom hier ausfällt, haben wir eine korrekte Datenmenge in EF_PLOG und EF_TM(x).

4. Atomare Ablauffolge – Brich den Kauf ab

Dies ist der letzte Schritt, in dem der, TRT-Zustand in EF-PLOG auf PurAbortCompletedE gesetzt werden muss. Es ist nicht notwendig, zwei Dateien zu synchronisieren, da wir den neuen Satz in dem Befehl "Initialize PSAM for Purchase" aktiviert haben.

Der Befehl benutzt einen neuen Satz in EF PLOG zum Arbeiten.

Arbeite mit der Datei EF PLOG:

Wenn der Strom hier ausfällt, gehen wir zu dem jetzt aktiven neuen Satz in EF_PLOG (mit dem Zustand PurInitializedE und inkrementiertem NIT) und dem noch aktiven alten Satz in EF_TM zurück. OK.

Aktiviere den Arbeitssatz in EF PLOG:

Wenn der Strom jetzt ausfällt, haben wir zwei aktuelle = aktive Sätze. Wir suchen immer nur nach dem ersten, d.h., wir finden den alten MIT DEM ZUSTAND PurInitializedE. Wir gehen zurück und verlieren die Informationen in dem neuen Satz, aber können den Befehl Abort Purchase wiederholen. Das ist noch in Ordnung.

Wenn der Strom jetzt ausfällt, haben wir einen aktiven Satz, der die korrekten Zähler usw. in EF LOG enthält.

PSALM – Abfolge beim Aufbuchen

Atomare Ablauffolge – Belaste LSAM

Arbeite mit der Datei EF_LOG:

1. Suche vom Anfang der Datei an, bis der erste aktuelle Satz (mit 01 als aktiv markiert) gefunden wird.
2. Markiere den nachfolgenden Satz mit 00 als inaktiv. Dies wird unser Arbeitssatz.
3. Kopiere alle Datenfelder aus dem aktiven Satz in den Arbeitssatz.
4. Aktualisiere den Arbeitssatz.

Ein Stromausfall findet EF LOG aktualisiert, aber TM, NIT, NC in EM_TM(NCR) nicht. Der Befehl kann nicht wiederholt werden. Wir müssen zu den alten Daten in dem aktiven Satz in EF_LOG zurückgehen. Das ist in Ordnung.

Wenn alles in Ordnung ist, arbeite mit EF_TM(x):

1. Suche vom Anfang der Datei an, bis der erste aktuelle Satz (mit 01 als aktiv markiert) gefunden wird.
2. Markiere den folgenden Satz mit 00 als inaktiv. Dies wird unser Arbeitssatz.
3. Kopiere alle Datenfelder aus dem aktiven Satz in den Arbeitssatz.
4. Aktualisiere den Arbeitssatz mit Daten, die bereits in EF_LLOG eingetragen wurden.

Wenn der Strom an dieser Stelle ausfällt, gehen wir zurück zu dem . aktuell aktiven Satz in EF_TM. Der Arbeitssatz in EF_LLOG wurde auch noch nicht aktiviert, so gehen beide Dateien zu der alten Information zurück.

Wenn der Strom jetzt ausfällt, haben wir zwei aktuelle = aktive Sätze. Wir suchen immer nur nach dem ersten, d.h., wir finden den alten. Wir gehen zurück und verlieren die Informationen in dem neuen Satz. Dies ist noch in Ordnung.

Claims

Verfahren zur Sicherstellung der Konsistenz von Daten, die in verschiedenen Dateien in Datensätzen gespeichert sind, wobei diese Datensätze durch eine Transaktion geändert werden, wobei jede Änderung eines Datensatzes einer Datei zur Anlegung von neuen Datensätzen in den von der Transaktion betroffenen Dateien führt, wobei das Verfahren durch folgende Schritte gekennzeichnet ist: a) Bestimmen einer von der Transaktion betroffenen Dateien als Primärdatei, wobei nur diese Datei Statusinformationen über den Erfolg der Durchführung der Transaktion enthält, wobei die Statusinformationen den Zustand „aktuell" oder „nicht aktuell" annehmen kann, b) Setzen der Statusinformation „aktuell" in jedem neu angelegten Primärdatensatz der Primärdatei, c) Prüfen, ob in der Primärdatei mehrere Primärdatensätze mit der Statusinformation „aktuell" enthalten sind, d) Rücksetzen der Statusinformation des Primärdatensatzes der Primärdatei, der dem neu angelegten Primärdatensatzes vorhergeht auf „nicht aktuell" und Belassen der Statusinformation „aktuell" des neu angelegten Primärdatensatzes, wenn kein Abbruch der Schreiboperation in einem Datensatz der von der Transaktion betroffenen Dateien festgestellt wird, bei Feststellung des Abbruchs der Schreiboperation in einem Datensatz der von der Transaktion betroffenen Dateien, Rücksetzen der Statusinformation des neu angelegten Primärdatensatzes auf „nicht aktuell" und Belassen der Statusinformation des vorhergehenden Primärdatensatzes der Primärdatei als „aktuell".
Verfahren nach Anspruch 1 dadurch gekennzeichnet, dass jeder Primärdatensatz einer Primärdatei Daten zur Identifizierung von. Datensätzen von Dateien, die von der Transaktion betroffen sind, enthält.
Verfahren nach Anspruch 1 dadurch gekennzeichnet, dass die der Primärdatei und die Datensätze der Dateien, die von der Transaktion betroffen sind, durch einen Pointer verkettet sind.
Computerprogramm zur Sicherstellung der Konsistenz von Daten, die in Dateien in Datensätzen im nichtflüchtigen Speicher eines Datenverarbeitungsgeräts abgespeichert sind, wobei die Datensätze durch eine Transaktion geändert wurden, wobei jede Änderung eines Datensatzes einer Datei zur Anlegung von neuen Datensätzen in den von der Transaktion betroffenen Dateien führt, wobei das Computerprogramm im nichtflüchtigen Speicher des Datenverarbeitungsgeräts speicherbar ist und bei Ausführung des Computerprogramms das Verfahren 1 – 3 ausgeführt wird.