Die Zukunft beginnt mit "Z" - Teil 3
von Jörg Linder
Heute geht es in die dritte und letzte Runde. Im vorigen Artikel hatte ich die verschiedenen Elemente vorgestellt, aus denen sich ein Z-System zusammensetzen kann. Sicherlich hat die Vielfalt bei einigen für Verwirrung gesorgt. Manche haben bestimmt nur den Kopf geschüttelt und nach den ersten Zeilen aufgehört, den Artikel zu lesen.
Inzwischen sind jedoch ein paar NZ-COM Neulinge hinzugekommen und auch ZDDOS / ZSDOS erfährt immer mehr Verbreitung. Die kinderleichte Installation trägt ihr übriges dazu bei. Wer augenblicklich noch nicht zu den Usern gehört, könnte aber in Kürze mit von der Partie sein. Um eventuelle Schwierigkeiten beim Einstieg zu überwinden, will ich an dieser Stelle ein paar Tips geben.
Als erstes muß man sich bei der neuen Systemsoftware zwischen ZDDOS und ZSDOS entscheiden. In der letzten Ausgabe hatte Mario Leubner bereits die wesentlichen Unterschiede erläutert. Für die Arbeit ohne NZ-COM bzw. unter CAOS empfehle ich ZDDOS. Zwar muß man dann auf den DOS-internen Suchpfad verzichten, doch dafür sind bereits die DateStamper-Funktionen integriert. Somit werden auch die CAOS-Aktivitäten mit Datum und Uhrzeit protokolliert. Übrigens könnte man unter CAOS den Suchpfad sowieso nicht beeinflussen.
Kann oder will man unter keinen Umständen auf die Vorzüge von ZSDOS verzichten und trotzdem die DateStamper-Funktionalität nutzen, gibt es auch dafür eine Lösung. Dazu muß im BIOS-Bereich ein ausreichend großer Raum für die entsprechenden Treiber geschaffen werden. Anwendern von NZ-COM ist ZSDOS auf alle Fälle zu empfehlen, da hiermit größtmögliche Funktionsvielfalt und Flexibilität erreicht wird. Durch die geschickete Kombination von DOS-internem Suchpfad und ZCPR-Kommandosuchpfad kann man alle Programme von nahezu allen Laufwerken und Nutzerbereichen benutzen. Treiber für Datumsstempel können in geschützten Bereichen untergebracht werden und beanspruchen nur wenig zusätzlichen Arbeitsspeicher.
Die Einrichtung der ZCPR-Umgebung erfordert ein wenig Überlegung. Während der Arbeit unter einer bestimmten Konfiguration stellt sich dann heraus, ob sie den eigenen Gewohnheiten entspricht oder geändert werden müßte. Spätestens dann lernt man NZ-COM zu schätzen, denn das Betriebssystem ist keine starre Einrichtung mehr, wo der Anwender den vom Programmierer vorgegebenen Beschränkungen ausgeliefert ist. Vielmehr kann man es den eigenen Bedürfnissen und Vorlieben anpassen.
Jeder der im 2. Teil dieser Artikelreihe vorgestellten Bestandteile einer ZCPR-Umgebung bringt eine gewisse Steigerung des Komforts mit sich. Es soll aber nicht unerwähnt bleiben, daß dafür auch Arbeitsspeicher gebraucht wird, der den kostbaren TPA schmälert. Durch die vom verfügbaren Arbeitsspeicher vorgegebenen Einschränkungen muß man seinen eigenen Kompromiß zwischen den Ansprüchen an den TPA und an den Komfort finden.
Einrichtung der ZCPR-Umgebung
Bevor ich mich diesem Thema eingehender widme, möchte ich darauf hinweisen, daß die hier beschriebene Vorgehensweise auf eigenen Erfahrungen beruht und nur eine Empfehlung darstellt. Selbstverständlich hat jeder die Freiheit, nach seinen Vorstellungen und Wünschen zu verfahren! Auf alle Fälle sollte der Aufforderung im NZ-COM Handbuch Folge geleistet und eine Kopie der Orginaldiskette angefertigt werden. Sämtliche Manipulationen werden nur an der Kopie durchgeführt!
Bereits bei der Definition der Umgebung (System-Deskriptor) werden Entscheidungen getroffen, die das Erscheinungsbild und die Funktionalität des späteren System festlegen. Ganz wichtig: Der System-Deskriptor muß unter der Systemkonfiguration erstellt werden, mit der später NZ-COM laufen soll, da die enthaltenen Informationen adreßabhängig sind.
Auf einzelne Elemente kann man verzichten (z. B. ein I/O-Paket), bei anderen zwischen verschieden großen Versionen wählen (z. B. RCP - residente Befehle) oder zusätzlichen Platz im hohen Speicher (UMA) für die DateStamper-Routinen reservieren. Dies alles sollte im Hinblick auf den verbleibenden TPA geschehen.
Logischerweise bieten größere Pakete auch mehr Funktionen, doch oftmals können auch kleine Utilities die Aufgaben übernehmen. Wer mit dem von MicroDOS gewohnten Befehlsumfang arbeiten möchte, kann die von Mario Leubner angepaßte Version des RCP10H benutzen. Der Dateibezeichnung ist zu entnehmen, daß sie im Speicher 10 Records (1 Record = 128 Bytes) belegt. Legt man Wert auf absolute Funktionsvielfalt, kann ein mehr als 20 Records großer RCP verwendet werden. Die untere Grenze stellt ein nur 4 Records großes Paket dar.
Analog gilt dies auch für den FCP. Weil die Programmteile bereits im Speicher stehen und nicht erst vom Datenträger geladen werden müssen, werden interne Kommandos schneller ausgeführt. Kommen jedoch Bedingungen (IF, ELSE ...) kaum zur Anwendung, dann kann man eine Minimalvariante des FCPs benutzen oder ganz darauf verzichten. Alle Funktionen des FCPs können auch von IF.COM ausgeführt werden. (Erfahrungsgemäß entdeckt man den Nutzen von bedingten Kommandoausführungen viel zu spät!)
Die Anzahl der benannten Verzeichnisse ist reine Geschmackssache. Für die einen sind 7 schon zu viel und für die anderen 21 noch zu wenig. Doch Achtung - alles hat seinen (Speicher-)Preis! Auf den ersten Blick scheinen die Namen nur schmückendes Beiwerk der Eingabeaufforderung im jeweiligen Verzeichnis zu sein. Weiter unten in diesem Artikel werde ich jedoch Beispiele für die Benutzung in Aliasen zeigen.
Eine Komponente sollte jedoch unverändert bleiben: der Shell Stack. Der Platz für vier Einträge dürfte allen Ansprüchen genügen. Ein Verzicht ist nicht zu empfehlen, da überaus nützliche Tools wie ZFILER oder LSH zur "Gattung" der Shells gehören und ohne den Shell Stack ihren Dienst verweigern.
Start des Systems
Bevor das System gestartet werden kann, müssen noch die benötigten Bestandteile in der Bibliothek NZCOM.LBR abgelegt werden. Verwendet man die Namen der bereits vorhandenen Module (mit "NZ" beginnend), so werden sie beim Start automatisch geladen. Dazu entpackt man am besten die gesamte Bibliothek und kopiert die benötigten Komponenten in dasselbe Verzeichnis. Dann wird die Originaldatei gelöscht und die neue umbenannt, so daß sie jetzt den Namen der alten hat.
Kleines Beispiel gefällig? Das standardmäßige DOS-Segment namens NZDOS.ZRL wird gelöscht. Anschließend ZSDOS.ZRL (oder ZDDOS.ZRL) in NZDOS.ZRL umbenannt. Ebenso wird mit RCP, FCP usw. verfahren. Ist alles erledigt, werden die Dateien wieder in die Bibliothek NZCOM.LBR gepackt. Ab sofort startet das Z-System automatisch mit dem neuen BDOS-Segment und den definierten Bestandteilen.
Das wird auch gleich ausprobiert. Während des Startvorgangs kann man am Bildschirm verfolgen, wie NZ-COM die Systemumgebung entsprechend den Festlegungen zusammensetzt, linkt und startet. Jetzt ist das Z-System aktiv und es kann losgehen. Um es jedoch optimal an die eigenen Bedürfnisse anzupassen, ist noch ein wenig einzurichten...
Zuallererst sollte die richtige Datei für die Terminalansteuerung installiert werden. Der im Handbuch beschriebene Weg über den Startalias ist etwas mühselig. Eleganter geht es, wenn man die entsprechende Datei in NZCOM.Z3T umbenennt und ebenfalls in die Bibliothek NZCOM.LBR packt. Dann wird sie beim Start automatisch geladen. Für optimale optische Ergebnisse sollte man INVERS.COM (/3) oder ZAS v1.1 (/4 und höher) mit der passenden Z3T-Datei verwenden, die mit der neuen Systemsoftware geliefert werden.
Anpassung des Systems
So, nachdem das System jetzt läuft, geht es ans Tuning. Dazu werden wir unseren KC nicht tieferlegen und mit einem Heckspoiler versehen, sondern ein paar Systemeigenschaften beeinflussen, die die Arbeit noch beschleunigen.
Zunächst geht's an die Pfade. Dazu sollte man sich den Unterschied zwischen dem DOS-internen Suchpfad und dem Kommandosuchpfad von NZ-COM verdeutlichen. Beide können mit ZPATH eingestellt werden, unterscheiden sich aber in der Funktionsweise erheblich. Um nicht nach jedem Start die Pfade neu einstellen zu müssen, sollte man die ZPATH-Kommandos im Startalias speichern. Erfahrene User können den Kommandosuchpfad in NZ-COM patchen; wie das geht, steht im Handbuch.
Das letzte Pfadelement im Kommandosuchpfad nimmt eine Sonderstellung ein. Es bezeichnet das sogenannte "Root-Verzeichnis". Einige Programme und NZ-COM selbst legen dort spezielle Dateien ab. Deshalb sollte dieses Verzeichnis mit Bedacht gewählt werden. Als äußerst praktisch hat es sich erwiesen, A15: als Root-Verzeichnis zu wählen, während auf der Festplatte (in C0: oder C15:) die Utilities gespeichert sind. Die Einstellung für den Kommandosuchpfad könnte also lauten:
A0 C0 C15 $$ A15.
Kommen wir nun zu einem der mächtigsten Werkzeuge eines Z-Systems. Der Alias. Was man darunter zu verstehen hat, ist im NZ-COM Handbuch beschrieben. Mit der von Helmut Jungkunz ausgelieferten Version bekommt man auch schon eine Reihe von Aliasen in der Datei ALIAS.CMD. Diese können selbstverständlich angepaßt oder um eigene Schöpfungen ergänzt werden. Hier sind benannte Verzeichnisse besonders nützlich.
Folgender Alias sorgt bei mir für den richtigen Durchblick:
HILFE command:help helpfile:$1.h?p
Sobald ich das Kommando HILFE, gefolgt vom Dateinamen einer HLP-Datei eingebe, wird im Verzeichnis "COMMAND:" das Programm HELP.COM aufgerufen. Diesem wird der Dateiname übergeben, jedoch die Verzeichnisangabe "HELPFILE:" vorangestellt. Daß sich hinter dem Verzeichnis "COMMAND" eigentlich C15: und hinter "HELPFILE" C14: verbirgt, ist für alle Beteiligten - Bediener und Programm - völlig uninteressant. Der Kommandoprozessor setzt die Befehlszeile in ein gültiges Format um.
Und was ist nun der Vorteil daran? Zum einen brauche ich mir keine Gedanken mehr darum zu machen, in welchem Verzeichnis sich HELP.COM befindet. Nun ja, das bräuchte ich bei entsprechender Pfaddefinition auch nicht. Zum anderen muß ich mich nicht darum kümmern, daß HELP.COM die gewünschte Helpdatei findet. Das könnte man sich aber zur Not auch noch merken. Wie elegant diese Lösung ist, merkt man aber, wenn z. B. das Standardverzeichnis für die Helpdateien gewechselt wird.
Angenommen, es soll nicht mehr C14: sondern D3: sein. Bei einer direkten Verzeichnisangabe müßten alle Verweise in allen Aliasen von C14: auf D3: geändert werden. Dank der benannten Verzeichnisse genügt aber nur eine einzige Änderung - nämlich in der Definition für den Verzeichnisnamen. Ähnliche Lösungen hat sich auch Mario Leubner für diverse CAOS-Programme eingerichtet:
BASICODE caos:;:dep3 basicode.uuu DEP e0:dep3 $td1$tu1:initial.uuu UNIPIC=UP unipic:;:dep3 initial.uuu WORDPRO,6=WP6 wp6:;:dep3 initial.uuu
Dies sind längst nicht alle Möglichkeiten, die das Z-System bietet. Aber der Artikel ist wieder länger geworden, als ursprünglich geplant. Ich hoffe, wenigstens bei einigen das Interesse geweckt zu haben. Zumindest ist erstmal Schluß mit dem ganzen Z-System-Zeugs. Aber nur hier in den News, auf dem KC geht's erst so richtig los! Schließlich beginnt die Zukunft für uns mit einem "Z".