Die Zukunft beginnt mit "Z" - Teil 2
von Jörg Linder
In der letzten Ausgabe hatte ich bereits angedroht, diese Artikelreihe fortzuführen. Diesmal dreht sich alles um "ZCPR", den Ersatz für das CCP Segment eines CP/M Systems. Ursprünglich wurde der ZCPR von verschiedenen Interessengemeinschaften entwickelt und erfuhr mit der Version 3.0 Richard Conn eine grundlegende Überarbeitung. Den (vorläufigen) Endstand schuf Jay Sage mit den Versionen 3.3 bzw. 3.4, die inzwischen den Standard darstellen.
Während der Anwender von den Veränderungen des BDOS-Segmentes zwar profitiert, diese jedoch kaum oder gar nicht bemerkt, ist beim CCP oftmals schon die kleinste Veränderung sofort zu spüren. Die aktuellen Versionen des ZCPR benügen sich jedoch nicht mit Kleinigkeiten - im Gegenteil: Das gesamte Anwenderinterface wird generalüberholt! Wie Mario Leubner bereits in der letzten Ausgabe andeutete, kann ein ZCPR aus etlichen Elementen bestehen, von denen hier einige vorgestellt werden.
Kommando Pakete
Der Kommando Prozessor (CPR) stellt dem Anwender nur drei Befehle zur Verfügung. Es kann eine Datei bzw. ein Programm ab 0100h in den Speicher geladen werden, das Programm ausgeführt werden und auf eine bestimmte Adresse gesprungen werden. Auf den ersten Blick recht mager! Doch dies ist nur die "Grundausstattung".
Jeder Anwender hat seine eigene Vorstellungen, welche Befehle für ihn unbedingt notwendig sind und auf welche er verzichten kann. Dank ZCPR kann man diese Vorstellungen verwirklichen. Dazu gibt es zwei weitere Kommando Pakete. Zum einen das "Resident Command Package" (RCP) mit residenten Befehlen und zum anderen das "Flow Command Package" (FCP) mit Befehlen zur Ablaufsteuerung. Im RCP können sehr einfache Befehle, wie z. B. POKE, ERA oder REN enthalten sein, aber auch sehr mächtige Kommandozeileneditoren. Die Größe des RCP ist dementsprechend variabel - von 0,5 bis 2,5 kByte ist so ziemlich alles drin.
Bis zu dieser Stelle dürfte einem normalen CP/M Anwender noch alles sehr vertraut vorkommen. Doch nun geht es mit den Neuerungen richtig los. Das zweite Kommando Paket - FCP - erlaubt in gewisser Weise die Programmierung in der Kommandozeile. Mit Befehlen wie IF, ELSE, AND, OR usw. können nachfolgende Anweisungen vom Erfolg oder Mißerfolg des vorherigen Kommandos abhängig gemacht werden. So kann z. B. überprüft werden, ob die angegebene Datei vorhanden ist oder einen bestimmten Dateityp hat. Dementsprechend kann das "richtige" Programm aufgerufen oder eine Fehlermeldung am Bildschirm ausgegeben werden. Mit diesen Befehlen bieten sich bei der Verwendung in Kommandoscripts und Aliasen ungeahnte Möglichkeiten.
Kommandosuchpfad
Konnte weder im CPR noch im FCP oder RCP das eingegebene Kommando gefunden werden, dann versucht der Kommandoprozessor (wie in jedem CP/M System) eine entsprechende COM- oder SUB-Datei zu finden. Die Suche ist aber nicht nur auf das aktuelle Laufwerk und den aktuellen Nutzerbereich beschränkt. Es kann ein Suchpfad mit maximal 5 Elementen definiert werden. Ein Element steht stellvertretend für eine Kombination aus Laufwerk und Nutzerbereich. Im Gegensatz zum ZSDOS-Pfad steht der ZCPR-Pfad nur während der Kommandosuche zur Verfügung. Programme wie WordStar oder dBase können ihre Overlays nicht entlang des ZCPR-Pfades finden! (Dazu kann nur der ZSDOS-Pfad verwendet werden.)
Erweiterter Kommandoprozessor
Wurde entlang des Pfades auch kein Programm entsprechend dem eingegebenen Befehl gefunden, kann die gesamte Befehlszeile in einem ZCPR-System an einen erweiterten Kommandoprozessor (ECP) übergeben werden. Dabei handelt es sich um ein spezielles Programm, das Kommandoscripts mit dem Namen des Befehls sucht und ausführt oder eine entsprechende COM-Datei aus einer Bibliothek extrahiert und ausführt. Der Name des ECP kann vom Anwender frei definiert werden. Nach dem Motto "Wer nicht will, der hat schon" kann auch ganz auf den ECP verzichtet werden.
Error Handler
Wird das Kommando nirgends gefunden (CPR, FCP, RCP, Pfad, ECP), müßte eigentlich eine Fehlermeldung erscheinen. Meistens hat man sich nur vertippt und dürfte nun die gesamte Zeile erneut eingeben. Hier kann ein optionaler Error Handler weiterhelfen. Die fehlerhafte Befehlszeile wird am Bildschirm wiedergegeben und kann bequem editiert werden. Anschließend wird die korrigierte Zeile wieder dem Kommandoprozessor übergeben.
Mehrfachkommandozeile
Ein normales CP/M System erlaubt nur die Eingabe eines Kommandos je Zeile. Mehrere Kommandos kann man über SUB-Dateien abarbeiten lassen. Allerdings muß man immer einen Editor zu Hilfe nehmen, wenn die SUB-Datei geändert werden soll. In einem ZCPR-System können beliebig viele Kommandos eingegeben werden, vorausgesetzt es wird die zur Verfügung stehende Anzahl Zeichen (über 200) nicht überschritten. Auf den ersten Blick ist kein Nutzen erkennbar, muß man doch weiterhin Kommando für Kommando eintippen - egal, ob nun in eine oder mehrere Zeilen.
Viele Z-System-Programme machen jedoch Gebrauch von Mehrfachkommandozeilen. Darüberhinaus wird die Schaffung eines völlig neuen Kommandotyps, Alias genannt, ermöglicht. Ein Alias ist ein einzelner Befehl, der stellvertretend für eine längere Kommandozeile oder mehrere Befehle steht. Ähnlich den SUB-Dateien können komplexe Aufgaben mit nur einem Befehl abgearbeitet werden. Allerdings können Aliase viel flexibler und mächtiger gestaltet werden als SUB-Dateien.
Terminal Capabilities Puffer
Terminals gibt es wie Sand am Meer. Jeder Hersteller hat seine Vorstellungen des "Standards" für Steuersequenzen verwirklicht. Viele Programme (wie z. B. WordStar) müssen vor der ersten Benutzung für ein spezielles Terminal installiert werden. Wer mit verschiedenen Computern arbeitet, muß in den meisten Fällen für jeden Computer eine entsprechende Version haben, sonst läuft nix.
Diesen Nachteil von CP/M Rechnern hebt der Terminal Capabilities Puffer (TCAP) auf. Es handelt sich um einen Bereich, in dem die Steuersequenzen des Terminals in einer definierten Datenstruktur hinterlegt sind. Z-System-Programme können auf diese Daten zugreifen und die benötigten Steuersequenzen "heraussuchen". Dadurch werden die Programme universell und laufen ohne Änderung auf jedem Computer mit vorhandenem TCAP.
Wheel Byte
Der Name dieses Bytes wurde von "The Big Wheel" (sinngemäß: großes Steuerrad) abgeleitet. Dabei handelt es sich um ein Kontrollelement des Systems für Sicherheitsfunktionen. Solange der in diesem Byte gespeicherte Wert gleich Null (00H) ist, können Dateien nicht gelöscht, umbenannt oder überschrieben werden. Diese Funktion lernt man spätestens dann schätzen, wenn sich mal ein "Systemfremder" über die Adreßdatei, den letzten Programmierversuch oder die neueste Beilagen-Diskette hermacht.
Benannte Verzeichnisse
Wer eine Festplatte oder eine große RAM-Disk sein eigen nennt, kennt sicherlich das Problem: Wo ist welche Datei gespeichert? War es C3, B7 oder D9? Bei 16 (oder 31) Nutzerbereichen wird man schneller vom Chaos beherrscht, als daß man es selbst beherrscht. Könnte man doch dem Verzeichnis mit allen dBase-Dateien den Namen "DBASE" geben... Mit ZCPR kann man! Der Name wird nicht nur an der Eingabeaufforderung angezeigt (z. B. "C3: DBASE>"), sondern auch von den meisten Z-System-Programmen unterstützt. Befehle, wie
DIR DBASE: oder CRUNCH WORK:*.* PACKED:
können genauso verwendet werden wie
DIR C3: bzw. CRUNCH A0:*.* D14:
Allerdings sind sie weniger kryptisch und für den Benutzer leichter zu merken. Benannte Verzeichnisse machen sich schnell "bezahlt", denn Ordnung ist bekanntlich das halbe Leben.
Shells
Hat ein Programm seine Arbeit erledigt, übernimmt das Betriebssystem wieder die Kontrolle. Unter normalen CP/M Systemen heißt das: Laden des CCP (falls er überschrieben wurde) und Anzeige des Systempromptes. Für Z-Systeme gibt es spezielle Programme, die sich wie eine Schale (Shell) um das System legen. Wird ein solches Programm aktiviert, dann wird anstelle des CCP die Shell mit der höchsten Priorität geladen und an sie die Kontrolle übergeben.
Auf dem Shell Stack stehen 4 Einträge zur Verfügung. Es können also maximal 4 Shells nacheinander gestartet werden. Jeweils eine Shell (die zuletzt aufgerufene) kann nur aktiv sein. Wird eine Shell beendet, wird die "darunterliegende" aktiv - sie sind sozusagen verschachtelt.
Wie sieht eigentlich eine Shell aus? Die Erscheinungsform kann sehr verschieden sein. So gibt es einfache History-Shells, deren Aktivität nur am Systemprompt zu erkennen ist. Sie zeichnen die eingegebenen Kommandozeilen auf, die später einfach per Tastendruck "durchgeblättert" und bequem editiert werden können. Andere Shells verändern das Erscheinungsbild vollkommen. ZFILER stellt das Directory eines Verzeichnisses auf dem Bildschirm dar. Mit einem Cursor können Dateien angewählt werden, um sie anschließend zu kopieren, zu löschen, Makros auf sie anzuwenden und, und, und ...
Zusammenarbeit von ZSDOS und ZCPR
Eigentlich würde schon ein Satz genügen: Die beiden arbeiten perfekt zusammen! Doch ein paar Einzelheiten sollen hier genannt werden:
Wie man sich denken kann, stellt der ZCPR gewisse Mindestanforderungen an das BDOS. Ein standardmäßiges BDOS hält da nicht mehr mit. Deshalb wird z. B. NZ-COM mit ZRDOS ausgeliefert. Dieses System enthält einige Erweiterungen gegenüber dem normalen CP/M BDOS. Alle Funktionen von ZRDOS werden von ZSDOS unterstützt, so daß es als Ersatz dafür eingesetzt werden kann. Außerdem bietet es etlichte neue Funktionen.
Dazu gehört z. B. das schnelle Wiedereinloggen "fester" Disketten. Nach einem Warmstart wird das Directory von Festplatten und RAM-Disks nicht erneut gelesen, was bei großen Verzeichnissen eine ganze Weile dauern kann. Dadurch wird die Arbeit mit derartigen Laufwerken erheblich beschleunigt.
Von ZCPR wird im Byte 13 des Dateisteuerblocks (S1 Byte) die Nummer des Nutzerbereichs abgelegt. Bisher wurde dieses Byte von keinem anderen BDOS benutzt. ZSDOS legt dort beim Öffnen einer Datei ebenfalls die Nummer des Nutzerbereichs ab. Anschließende Lese- und Schreiboperationen können durchgeführt werden, ohne daß zuvor die BDOS Funktion zum Setzen des Nutzerbereichs aufgerufen werden muß.
Unter ZSDOS hat man die Möglichkeit, einen von vier Fehlermodi zu wählen. MicroDOS bot zwar mit einem Funktionsaufruf auch schon die Unterdrückung der Fehlermeldungen am Bildschirm und die Übergabe von erweiterten Fehlercodes an das rufende Programm, doch die ZSDOS Funktion hält auch was sie verspricht. (Was man von MicroDOS leider nicht behaupten kann.)
Durch die geschickte Kombination des internen ZSDOS Pfades und des ZCPR Kommandosuchpfades kann man das System so einrichten, daß nahezu jede Datei bzw. jedes Programm von überall gefunden und gestartet wird.
Sicherlich fühlen sich jetzt einige überfordert: die vielen Abkürzungen, die vielen Funktionen ... und auch noch selbst einrichten?! Es verlangt aber niemand, daß man alles auf Anhieb versteht oder gar auswendig lernt. Vielmehr sollte man sich mit den einzelnen Komponenten vertraut machen und erst dann entscheiden, ob sie für den eigenen Gebrauch sinnvoll sind. So nach und nach ergibt es sich dann, daß man "sein" System zusammenstellt und der eigenen Arbeitsweise anpaßt. Und genau für diesen Zweck wurde ZCPR entwickelt. Das Betriebssystem bietet keine starren Vorgaben mehr, sondern eine Plattform, auf der Komponenten nach den eigenen Wünschen installiert werden.
So, das war jetzt aber eine ganze Menge. (Soviel hatte ich gar nicht geplant.) Bis zur nächsten Ausgabe werden sicherlich schon einige das neue System installiert haben. Dann kann ich vielleicht schon neben ein paar Anwendungsbeispielen auch Problemlösungen anbieten.