MTOOLS -- Version 1.3
von Frank Dachselt
Mit den höheren Übertragungsraten des M051 rücken nun auch verschiedene neue Anwendungen für die Rechnerkopplung in akzeptable Nähe. Die interessanteste davon dürfte sicherlich ein Festplatten-Backup vom KC auf den PC sein. Bisher war für solche Aktionen nicht nur ausreichend Geduld gefragt, sondern auch viel Vertrauen in die Übertragungssicherheit der Kabelverbindung, denn es erfolgte kein Test, ob die Dateien auch fehlerfrei übertragen wurden.
Die MTOOLS der Version 1.3 besitzen nun einen solchen Test. Dieser vergleicht jeweils die CRC-Werte der Quell- und der Zieldatei miteinander und kann auf diese Weise Übertragungsfehler erkennen. Damit schließt die Übertragungssicherheit der Kabelverbindung zu der von Diskette und Festplatte auf. Nun kann man guten Gewissens ein Back-Up mit Hilfe der MTOOLS anlegen und im Ernstfall die Dateien auf dem KC wieder rekonstruieren.
Funktionell geändert haben sich nur die Programme MGET.COM und MPUT.COM, da nur diese Dateien auf den jeweils anderen Rechner übertragen und abspeichern. Trotzdem empfehle ich, alle Programme aus dem Archiv MTOOLS13.PMA zu übernehmen, damit alle Kommandos die gleiche Versionsnummer zeigen. Eine ausführliche Installationsbeschreibung - auch für Neueinsteiger - ist in dem PC-Archiv MTOOLS13.ZIP enthalten. Ich werde im folgenden nur auf die Neuigkeiten eingehen.
Die KC-seitige CRC-Berechnung ist in die Kommandos MGET und MPUT integriert und läuft parallel zum Empfang bzw. zum Senden der Dateien ab. PC-seitig übernimmt das das Programm MCRC.EXE jeweils am Ende einer Übertragung. MCRC.EXE befindet sich im Archiv MTOOLS13.ZIP und muß in das gleiche Verzeichnis kopiert werden, in dem sich auch schon UUENCODE.COM und UUDECODE.COM befinden. Damit ist die CRC-Aufrüstung der MTOOLS bereits erledigt.
Nachdem MGET und MPUT eine Datei empfangen bzw. gesendet haben, werden jetzt neben der Anzahl der übertragenen Bytes auch die CRC-Werte für die Datei auf dem KC (l = lokal) und die Datei auf dem PC (r = remote) angezeigt. Stimmen beide Werte überein, dann war die Übertragung fehlerfrei und die Programme gehen - soweit vorhanden - zur nächsten Datei über. Im Fehlerfall - also bei unterschiedlichen CRC-Werten - wiederholen die Programme die Übertragung der betreffenden Datei bis sie fehlerfrei übertragen wurde oder die maximale Anzahl von Wiederholungsversuchen erreicht ist. Diese Anzahl kann mittels der Option -0 bis -9 beim Aufruf der Programme auf Werte zwischen 0 und 9 gesetzt werden. Fehlt diese Angabe, wird der Vorgabewert 2 benutzt.
An dieser Stelle ein Hinweis zur Angabe von Optionen, der für alle Programme des MTOOLS-Paketes gilt: Sollen mehrere Optionen gleichzeitig angegeben werden (zur Zeit ist das bei MGET.COM und MPUT.COM sinnvoll), dann müssen diese zu einer Zeichenkette mit einem führenden "-" zusammengefaßt werden. Die Reihenfolge der Optionen ist dabei beliebig. Als Beispiel wird mit der folgenden Kommandozeile der Empfang der Datei ARCHIV.PMA als Binärdatei mit maximal 9 Wiederholungsversuchen ausgelöst:
A0>MGET -B9 ARCHIV.PMA
Sind alle in der Kommandozeile spezifizierten Dateien übertragen, folgt noch eine kurze Statistik, aus der hervorgeht, wieviele der angegebenen Dateien fehlerfrei übertragen wurden, ob es Übertragungsfehler (= Wiederholungsversuche) gab und ob dies letztlich zu fehlerhaften Dateien geführt hat. Kann eine Datei nicht fehlerfrei übertragen, dann wird sie auf dem Zielrechner nicht gelöscht, sondern verbleibt dort in dieser fehlerhaften Form!
Neu hinzugekommen als KC-seitiges Kommando ist das Programm MCRC.COM. Wie der Name bereits vermuten läßt, entspricht es dem Programm MCRC.EXE auf der PC-Seite. MCRC bestimmt für die angegebenen lokalen KC-Dateien (Jokerzeichen sind erlaubt) die CRC- Werte und gibt sie im gleichen Format (Dateilänge, CRC, Dateiname je Datei in einer Zeile) wie das PC-Gegenstück aus. Wie die Kommandos MGET und MPUT arbeitet auch MCRC im Normalfall im Textmode; sollen Binärdateien verarbeitet werden, dann muß die Option -B angegeben werden (dazu später mehr). Im Gegensatz zu den anderen MTOOLS-Kommandos arbeitet MCRC nur lokal und greift nicht auf die Koppelschnittstelle zu. So kann also auch noch nachträglich die Fehlerfreiheit von Dateien auf beiden Rechnern überprüft werden. Für eine größere Anzahl von Dateien protokolliert man günstigerweise die Ausgaben der Programme in Textdateien (auf dem KC z.B. mittels CAPTURE.COM) und vergleicht sie danach mit Hilfe eines der bekannten Differenzprogramme für Textdateien.
Eine Grenze, die bei der Verwendung der MTOOLS zu beachten ist, betrifft die Anzahl der mit einem Aufruf übertragbaren Dateien, wenn Jokerzeichen bei der Angabe verwendet werden. Da alle Dateinamen zunächst im TPA Platz finden müssen, ist diese Anzahl beschränkt. Bei MPUT verwende ich zur Auflösung der Jokerzeichenstrings eine Bibliotheksroutine, die diese Anzahl unabhängig von der resultierenden Länge der Namen auf 513 (= 2^9 + 1) begrenzt. Sollten mehr Dateien der angegebenen Spezifikation genügen, werden die überzähligen Namen ignoriert. Bei MGET habe ich die Dinge dagegen selbst in der Hand und habe hier die alte Beschränkung von 256 Dateien auf jetzt 2048 erweitert. Insgesamt darf die Länge aller Dateinamen aber 24 KByte nicht überschreiten, was bei maximaler Länge der Namen (jeweils 8 + 3) auch etwas weniger als 2048 sein können. Auch bei MGET werden beim Überschreiten dieser Grenzen die restlichen Dateien ignoriert, hier erfolgt aber zumindest eine entsprechende Meldung auf dem Bildschirm.
Back-Up der Festplatte mit den MTOOLS
Bei einem Back-Up überträgt man ja vorzugsweise ganze Verzeichnisse vom KC auf den PC. Das geschieht am besten userbereichsweise mit der Dateiangabe "*.*". Falls jemand mehr als 513 Dateien in einem Userbereich hat, dann müssen diese Dateien geeignet gruppiert und mit separaten Aufrufen von MPUT übertragen werden. Eine solche Gruppierung kann man z.B. anhand der Dateierweiterungen (wenn deren Anzahl in dem betreffenden Userbereich überschaubar ist) oder mit den Anfangsbuchstaben der Dateinamen vornehmen. Z.B.:
D9>MPUT -B *.PIP oder D9>MPUT -B A*.* D9>MPUT -B *.PIF D9>MPUT -B B*.* D9>MPUT -B *.HIP D9>MPUT -B C*.* D9>MPUT -B *.HIF ... D9>MPUT -B *.DSH D9>MPUT -B Z*.*
Für diese Kommandofolgen legt man natürlich am besten eine SUB-Datei an. Bei der Rückübertragung zum KC kann man dann bis zu 2048 Dateien mit einem Aufruf übertragen. Hat jemand tatsächlich mehr Dateien in einem Userbereich?!
Es empfiehlt sich, bei solchen langwierigen Übertragungen die Ausgaben der Übertragungskommandos in eine Textdatei (auf ein anderes Laufwerk) zu protokollieren, damit man im nachhinein überprüfen kann, ob Fehler aufgetreten sind. So kann man ein Back-Up auch mal über Nacht laufen lassen und braucht den Vorgang nicht ständig beobachten.
Wenn eine Dateiangabe mit Jokerzeichen auch Binärdateien einschließt, dann muß die gesamte Übertragung - wie in den obigen Beispielen - mit der Option -B erfolgen. Auch in diesem Fall kann man die Dateien geeignet gruppieren, damit man Textdateien nicht unnötigerweise als Binärdatei überträgt, was ja durch die UUE-Kodierung etwa 30% länger dauert.
Text-, Binär- und Null-Byte-Dateien
An dieser Stelle möchte ich auch noch einmal auf die unterschiedliche Behandlung von Text- und Binärdateien eingehen, da mit der neu hinzugekommenen CRC-Überprüfung diese Problematik noch etwas verschärft wird. Da im CP/M-Directory die Dateigröße immer nur als ein Vielfaches von 128 Byte (eine Sektorlänge) angegeben ist, müssen für die Bestimmung der exakten Dateilänge spezielle - meist programmspezifische - Kennzeichnungen verwendet werden. Für Textdateien ist es das EOF-Zeichen (1Ah). Gleichzeitig ist EOF auch die Ende-Kennzeichnung für das von uns verwendete Übertragungsverfahren über die serielle Schnittstelle. Aus diesem Grund unterscheiden wir hier überhaupt zwischen Text- und Binärdateien, wobei Binärdateien eben alle die Dateien sind, die nicht zu den Textdateien gehören.
Im Dateisystem auf dem PC wird dagegen die exakte Länge einer Datei gespeichert, so daß die Notwendigkeit spezieller Kennzeichnungen entfällt - auch bei Textdateien. Eine Konsequenz daraus ist, daß Dateien auf dem KC und dem PC unterschiedliche Längen habe können, obwohl sie "logisch" völlig identisch sind. Eine Textdatei vom KC wird deshalb nur bis zum Auftreten des EOF-Zeichens an den PC übertragen und dort mit dieser exakten Länge (ohne das EOF-Zeichen, was auf dem KC Bestandteil der Datei ist) gespeichert. Zwar könnte man eine Textdatei auch als Binärdatei behandeln, dann würde sie auf dem PC die Länge eines Vielfachen von 128 Byte haben. Allerdings erscheinen dadurch am Dateiende zusätzliche zufällige und meist störende Zeichen, da das EOF-Zeichen in Textverarbeitungen oft nicht mehr als solches interpretiert wird.
Bei einem Back-Up auf dem PC, bei dem die KC-Dateien auf dem PC ja nicht weiterverarbeitet werden sollen, stört das natürlich nicht. In diesem Fall können also alle Dateien als Binärdateien übertragen werden, ohne daß Datenverluste oder Nebeneffekte - abgesehen von der längeren Übertragungszeit - auftreten.
Dennoch ist dabei einiges zu beachten, da die CRC-Bestimmung auf beiden Rechnern von der gleichen Dateilänge ausgehen muß, um einen sinnvollen CRC-Wert zu bestimmen:
Textdateien, die als Binärdatei zum PC übertragen wurden, müssen auch in der Gegenrichtung (vom PC zurück zum KC) als Binärdatei übertragen werden. Sollen die CRC-Werte solcher Dateien mit den MCRC- Kommandos auf beiden Rechnern bestimmt werden, dann muß auf dem KC der Binärmode (Option -B) verwendet werden.
Bei Binärdateien, die auf dem PC erstellt oder bearbeitet wurden und anschließend auf den KC übertragen werden, wird während des MGET-Kommandos eine exakte CRC-Bestimmung durchgeführt. Ein nachträglicher CRC-Vergleich mit den MCRC- Kommandos ist dagegen nicht sinnvoll, da sich die Dateilänge auf dem KC im allgemeinen von der auf dem PC unterscheidet.
Beim Transport von Dateien mittels Diskette zwischen den Rechnern, werden diese immer als Binärdatei übertragen. In der Richtung KC --> PC erhält man nur dann die richtigen CRC- Werte, wenn auf dem KC die Option -B im MCRC-Kommando angegeben wird. Nach einem Transport in der Gegenrichtung (PC --> KC) ist der CRC-Vergleich in den meisten Fällen nicht sinnvoll, insbesondere wenn die Datei auf dem PC erstellt oder bearbeitet wurde (siehe vorhergehenden Absatz).
Zu guter Letzt benötigen auch leere Dateien noch etwas Aufmerksamkeit: Werden leere Textdateien (Datei enthält das Byte 1Ah an erster Stelle) oder Null-Byte-Binärdateien (Datei belegt 0 Sektoren) im Textmode (ohne Option -B) von KC auf den PC übertragen, dann wird auf dem PC keine Datei angelegt. Der CRC-Test reagiert darauf mit einer Fehlermeldung und eventuellen Wiederholungsversuchen. Eine eventuell zuvor auf dem PC vorhandene Datei gleichen Namens wird dabei gelöscht.
Leere Textdateien und Null-Byte-Binärdateien müssen darum stets als Binärdatei (mit Option -B) zum PC übertragen werden. Eine solche Textdatei belegt dann auf dem PC 128 Byte, die Binärdatei dagegen bleibt eine Null-Byte-Datei. Wenn eine leere Textdatei vom KC auf dem PC 128 Byte belegt, dann sollte die Rückübertragung zum KC ebenfalls mit der Option -B erfolgen, da anderenfalls zwar die Datei richtig übertragen, aber dennoch ein CRC-Fehler erkannt wird und eventuelle Wiederholungsversuche beginnen.
Die Übertragung leerer Dateien in Gegenrichtung (vom PC zum KC) funktioniert dagegen sowohl im Text- als auch im Binärmode fehlerfrei.
Damit genug der Feinheiten! Wenn sich also einmal unterschiedliche CRC-Werte ergeben sollten, dann muß das nicht unbedingt auf einen Übertragungsfehler hindeuten. Im Gegenteil: Da die Übertragung mit dem seriellen Kabel doch recht sicher erscheint, ist bei einem CRC- Fehler wahrscheinlich einer der obigen Punkte nicht beachtet worden. Ich habe bei meinen Versuchen mit inzwischen mehreren Mega-Bytes übertragener Daten bisher - außer den selbst provozierten - noch keinen echten Übertragungsfehler feststellen können. Trotzdem schläft man natürlich besser, wenn man weiß, daß es den CRC-Test gibt.
Ausblick
Nachdem die Übertragung über das serielle Kabel ausreichend sicher geworden ist, geht es nun um Geschwindigkeit und Komfort. Um die Anwendung der MTOOLS bequemer zu machen, habe ich mir für die nächste MTOOLS-Version eine Log-Datei und die halbautomatische Erkennung von Text- und Binärdateien vorgenommen. Außerdem gibt es verschiedene Reserven für höhere Geschwindigkeiten, die schließlich die Möglichkeiten der vorhandenen Hardware besser ausnutzen werden.