Die Flexibilität des Z-Systems schafft es immer wieder, selbst langjährige Anwender zu begeistern. Natürlich wünscht man sich den größtmöglichen Komfort und installiert demzufolge leistungsfähige Systemelemente.
Selbstverständlich benötigen diese auch Speicherplatz. Ein Maximal-System bietet zwar allen erdenklichen Komfort, jedoch ist die verbleibende TPA so klein, daß man eigentlich nicht mehr damit arbeiten kann. Es gilt also, ein ausgewogenes Verhältnis zwischen Größe und Komfort zu finden.
Inzwischen sind zahlreiche Varianten der Systemelemente verfügbar. Zum Teil steht sogar der Quelltext zur Verfügung und man kann ihn durch einfache Ja-/Nein-Entscheidungen anpassen bzw. festlegen, welche Befehle und Funktionen enthalten sein sollen. Es ist zweckmäßig, vor Installation einer bestimmten Variante genau zu überlegen, was unbedingt benötigt wird. Auch eine Überprüfung des Systems von Zeit zu Zeit ist empfehlenswert. Hat man im Laufe der Zeit (s)einen eigenen Arbeitsstil entwickelt, findet man garantiert ein paar überflüssige Funktionen.
Doch man muß sich nicht nur auf Teile von Systemelementen beschränken, sondern kann im Einzelfall das auf eine oder andere Modul gänzlich verzichten. Bestes Beispiel hierfür ist das IOP (Input/Output Package). Es beinhaltet entweder sehr systemspezifische Routinen für einen bestimmten Computertyp wie z. B. einen Tastaturtreiber oder bietet selten benötigte Funktionen wie z. B. Umleitung der Druckausgabe in eine Datei.
Im Kapitel 6 des NZ-COM Handbuches ist der Aufbau der Z-System Umgebung beschrieben. Standardmäßig werden neben CPR und DOS folgende Elemente installiert: Warmboot-Umleitung, Environment Descriptor, TCAP, Message Puffer, Pfad, Wheel Byte, externer FCB, Kommandozeilenpuffer, externer Kommandoprozessor-Stack, Shell Stack, optionaler Benutzerspeicher, NDR, RCP, FCP und IOP. Mittels MKZCM kann auf alle genannten Elemente ab Shell Stack (dieser eingeschlossen) Einfluß genommen werden. Gibt man für die Größe "0" ein, so wird das jeweilige Element nicht installiert.
Nun sollte man keinesfalls das System einer Radikalkur unterziehen. Auch wenn man im ersten Augenblick zu der Überzeugung gelangt ist, man könne auf ein Systemelement verzichten, sollte man sich überlegen, ob eine Minimalvariante vielleicht doch Platz hätte. (Überdies kann das System jederzeit "im Flug" gewechselt werden.) Ein gutes Beispiel hierfür ist der Shell Stack. Sehr schnell erliegt man der Versuchung, ihn mit dem Hintergedanken "brauch' ich eh' nicht" aus dem System zu entfernen. Doch spätestens beim Versuch, ZFILER oder LSH zu starten, besinnt man sich eines besseren.
Beim RCP ist die Auswahl verfügbarer Varianten groß und dementsprechend ist der Leistungsumfang sehr verschieden. Neben den standardmäßigen Paketen gibt es inzwischen auch Spezialversionen für den KC. Schon nach relativ kurzer Zeit stellt man fest, daß einige Befehle (z. B. REG, PORT, WHL) nie benutzt werden. Dort sollten die Aufräumungsarbeiten beginnen. Die Einsparungen können hier recht üppig ausfallen -- von 9 oder 10 Records auf minimale 4 Records. Werden einige Kommandos doch hin und wieder benötigt, muß man deshalb nicht gleich eine neue Systemumgebung laden. Die Funktionen von vielen internen Befehlen lassen sich durch ein entsprechendes Programm nachbilden -- etliche sogar als Typ-3 oder Typ-4.
Ähnliches gilt für den FCP. Lediglich die standardmäßig installierte Variante ist nicht ganz so groß, daß man gegenüber der Minimalversion so gravierende Einsparungen machen könnte wie beim RCP. Doch nichtsdestotrotz lohnt es sich auch hier, auf einige Befehle und somit auf ein paar Bytes zu verzichten. Das absolute Minimum stellen die vier Befehle IF, ELSE, FI und ZIF dar. Diese genügen für die meisten Anwendungsfälle und sollten resident im Speicher verbleiben, um einen schnellen Zugriff zu gewährleisten. Alle anderen Funktionen (z. B. Test auf Vorhandensein einer Datei mit EXIST, Zugriff auf Userregister) können dem Programm IF.COM überlassen werden. Es muß sich nur im Root-Verzeichnis befinden und schon wälzt der Kommandoprozessor alle Befehle zur Fluß Steuerung, die nicht intern vorhanden sind, auf dieses Programm ab.
Völlige Freiheit besitzt man bei der Definition der "benannten Verzeichnisse" (Named Directories, NDR). Weder das System noch irgendwelche Programme sind darauf angewiesen, weshalb man auch ganz darauf verzichten kann. Die Namen erscheinen an der Eingabeaufforderung und erleichtern so die Orientierung im Dschungel der Verzeichnisse. Außerdem können sie, wie bereits in meiner Artikelreihe geschildert, in Scripts und Makros benutzt werden. Während der Konfiguration mit MKZCM wird nur die Anzahl der maximal verfügbaren Namen festgelegt. In einem Record haben jeweils sieben Namen Platz. Das klingt zunächst nicht sehr speicherhungrig, aber so mancher fühlt sich erst mit dreißig oder vierzig benannten Verzeichnissen so richtig wohl. Hier gilt also: Die Masse macht's.
Lange Zeit konnte der optional verfügbare Benutzerspeicher (User Memory Area, UMA) vernachlässigt werden. Erst mit ZSDOS/ZDDOS gewinnt er durch die Möglichkeit, dort die Treiber für Datums- und Uhrzeitstempel unterzubringen, an Bedeutung. Selbstverständlich gilt auch hier, sich auf die notwendigsten Routinen zu beschränken. Bei den mitgelieferten und verfügbaren Systemelementen ist stets der Platzbedarf im System angegeben, nicht so bei der UMA. Hier muß der Anwender selbst feststellen, wieviele Records der gelinkte (!) Treiber benötigt. Grundsätzlich gilt hierbei, daß ein Zuviel nicht schaden kann. Doch was nutzt es, wenn man bei RCP und FCP spart, während hier die Bytes "mit vollen Händen rausgeschmissen" werden.