Transaktionskontrolle

Da für Dateiübertragungen mit dem NetzWerk-Programm keine obere Schranke für die Übertragungszeit angegeben werden kann, ist es nützlich, den Fortschritt einer aktiven Transaktion prüfen zu können.

Dies geschieht, indem der Benutzer nach Selektion des Menüpunktes ,,Transaktionskontrolle`` den Transaktionscode sowie den Zielknoten angibt. Der Algorithmus ermittelt daraus den Ursprungsknoten (der lexikalisch im Transaktionscode enthalten ist) und prüft, ob ein NWP-Knoten auf der Route zum Zielknoten eine Datei mit dem Präfix DA zum gegebenen Transaktionscode in ihrem Eingangsbereich enthält.
Die zum Transaktionscode gehörende DA-Datei kommt auf der gesamten Route nur an einem einzigen NWP-Knoten vor, da sie gelöscht wird, sobald die im Arbeitsbereich des Knotens befindliche DW-Datei an den Sendeserver übergeben wurde und dieser die DW-Datei auf dem nächsten NWP-Knoten in eine DA-Datei umbenennen konnte .
Derjenige NWP-Knoten, in dessen Eingabebereich eine DA-Datei liegt, muß folglich der für diese Transaktion aktuelle Knoten sein.

Analog zu den DA-Dateien werden auch die Quittungsdateien (Präfix QU) gehandhabt. Hier läßt sich anhand des Vorhandenseins der QU-Datei im Eingabebereich der NWP-Knoten ermitteln, wie weit die Transaktion fortgeschritten ist.

Es muß daher zwischen drei Fällen unterschieden werden:

1.

Im Eingabebereich des Knotens ist die zum Transaktionscode passende DA-Datei abgelegt:
Die Transaktion befindet sich in der Übertragungsphase und der NWP-Knoten ist der gesuchte Knoten.

2.

Im Eingabebereich des Knotens ist die zum Transaktionscode passende QU-Datei abgelegt:
Zur Zeit läuft die Rückübertragung der Quittung, die an diesem Knoten angekommen ist.

3.

Im Eingabebereich des Knotens ist weder eine DA- noch eine QU-Datei enthalten:
Dieser Knoten liefert keine für die Aufgabenstellung verwertbaren Informationen. Aus seiner Wegedatei wird daher der nächste Knoten ermittelt.

Zu beachten ist, daß die Quittungsdatei immer dieselbe Route wie die Datendatei nimmt; die Reihenfolge der Knoten kehrt sich allerdings um.

Der folgende Algorithmus realisiert dieses Szenario:

EINGABE(Transaktionscode);
EINGABE(Zielknoten);

ERMITTLE Ursprungsknoten AUS Transaktionscode;
Aktueller_Knoten := Ursprungsknoten;
gefunden := FALSE;
Eingabebereich := /usr/spool/nw/tmp;

SOLANGE (nicht gefunden)
   
   LOGIN (Aktueller_Knoten);
   Logoutknoten := Aktueller_Knoten;

   FALLS DATransaktionscode-Datei IN Eingabebereich
         \\ 1. Fall: DA-Datei gefunden
         AUSGABE "Daten an" Aktueller_Knoten "eingetroffen";
         gefunden := TRUE;

   SONST FALLS QUTransaktionscode-Datei IN Eingabebereich
               \\ 2. Fall: QU-Datei gefunden
               AUSGABE "Quittung an" Aktueller_Knoten "eingetroffen";
               gefunden := TRUE;

         SONST \\ 3. Fall: Suche fortsetzen mit naechstem Knoten
               ERMITTLE Naechster_Knoten ZU Aktueller_Knoten AUS \\
                                                       Wegedatei;
               Aktueller_Knoten := Naechster_Knoten;

   LOGOUT (Logoutknoten);
 ;
ENDE

Diese Funktion kann auch dazu benutzt werden, im Falle eines ausgefallenen Knotens herauszufinden, welchen Namen dieser Knoten hat. Vorausgesetzt wird in diesem Fall, daß eine Störung der NWP-Software (Control Program, Empfangs- und Sendeserver) vorliegt; bei Fehlern in der Infrastruktur eines Knotens ist dieser Algorithmus natürlich machtlos.
Sollte das Control Program ausfallen, legt der Empfangsserver alle erhaltenen Dateien zwar weiterhin im Eingangsbereich ab; sie können aber nicht mehr umbenannt werden und bleiben als DA- oder QU-Dateien im Eingangsbereich liegen. Da der obengenannte Algorithmus nach bestimmten DA- bzw. QU-Dateien sucht, kann der defekte NWP-Knoten schnell gefunden werden.