Kapitel 5
In den vorangegangenen Kapiteln haben Sie die grundlegenden Funktionen des Z-Systems und der besonderen Implementation in NZ-COM kennengelernt. Was Sie gesehen haben, ist jedoch nur die Spitze eines Eisbergs! NZ-COM bietet eine Unzahl an Möglichkeiten und wir werden versuchen, sie Ihnen in diesem Kapitel vorzustellen. Tatsächlich gibt es sicher Anwendungen für NZ-COM, die nicht einmal uns eingefallen wären, daher können wir hier nicht Anspruch auf erschöpfende Behandlung erheben.
5.1 Alternativer Aufruf von NZ-COM
Bisher haben Sie die einfachste Methode kennengelernt, NZ-COM zu starten. In diesem Abschnitt werden wir einige andere Wege diskutieren, das Z-System zu laden und einige andere Versionen des Systems, die fast ebenso leicht geladen werden können, wie die bereits gesehene.
5.1.1 Alternative Lademethoden
Sie haben die Standardmethode, NZCOM zu starten, kennengelernt, die in der Eingabe des einfachen Befehls besteht:
NZCOM<cr>
NZCOM kann auch auf folgende Weise geladen werden:
Eine NZCOM-Kommandozeile kann in einer SUBMIT-Datei enthalten sein, die entweder unter CP/M oder unter dem Z-System abläuft. Das Kommando NZCOM in einer SUB-Datei kann nützlich sein für den automatischen Aufruf von NZCOM als Teil Ihrer CP/M Kaltstart-Prozedur. Siehe dazu auch Abschnitt 5.4.4 für Information über ausgefeiltere Verwendungsarten von SUBMIT mit NZ-COM.
NZCOM kann auch als Teil einer Mehrfach-Kommandozeile gestartet werden. Zum Beispiel:
NZCOM nzcom-parameter;Befehl 1;Befehl 2;...<cr>
startet NZCOM mit dem Parameter und dann das Kommando Befehl 1 nach dem ";" usw. In diesem Fall wird das Default Start-Kommando (normalerweise STARTZCM) nicht ausgeführt. Zum Beispiel wird
NZCOM ;MYSTART<cr>
die Standard NZ-COM-Konfiguration laden und dann das alternative Startup Kommando MYSTART. Bedenken Sie jedoch, daß diese Lade-Technik nicht mit der SUBMIT Lade-Technik kombinierbar ist.
5.2 Anpassen Ihres NZ-COM Systems
Es gibt viele Möglichkeiten, Ihr NZ-COM-System anzupassen und es auf Ihre Bedürfnisse und Ihren Geschmack einzustellen. Wir wollen zwei Arten von Änderungen in Betracht ziehen, jene, welche Sie mehr oder weniger vorübergehend anlegen und jene, die Sie eher permanent machen, etwa durch Eingabe einer komplett neuen Konfiguration.
5.2.1 Vorübergehende Änderungen
Nachdem Sie sich mit den Grundlagen des NZ-COM-Systems etwas vertrauter gemacht haben, möchten Sie zweifellos eine Reihe der System-Charakteristika ändern. Einige dieser Änderungen werden vorübergehender Natur sein. Sie möchten zum Beispiel den Command Search Path (Suchpfad) ändern, um ein Directory mit solchen Dateien zu erfassen, die Sie nicht ständig benützen -- und die daher normalerweise nicht im Suchpfad liegen -- aber die Sie für die momentane Aufgabe brauchen. Dazu benützen Sie das PATH-Utility. Haben Sie ihre Arbeit damit beendet, benützen Sie wiederum dieses Utility, um den Pfad auf seine ursprüngliche Einstellung zurückzusetzen.
Andere Parameter, die oft temporär geändert werden, sind die Charakteristika von Drucker und CRT (Cathode Ray Tube = Kathodenstrahlröhre = Bildschirm). Viele Z-System-Programme werden sich automatisch auf diese "Environment" Werte einstellen. Zum Beispiel, wenn Sie mit einem Zeilenabstand von 6 Zeilen pro Zoll drucken, könnten Sie die Druckerdaten auf 66 Zeilen pro Seite und 58 Textzeilen einstellen. Wenn Sie mit 8 Zeilen pro Zoll drucken, benützen Sie statt dessen Werte von 88 und 78. Man verwendet dafür das CPSET-Utility.
Manchmal möchten Sie derartige Veränderungen über einen gewissen Zeitraum beibehalten, aber nicht fest einbinden. In diesem Fall, können Sie die benötigte Befehlszeile Ihrem Startup Alias beifügen. Die Veränderungen treten dann automatisch in Kraft, wenn Sie das NZ-COM-System erstmals starten (und nach jedem Kaltstart).
5.2.2 NZ-COM Deskriptor-Dateien
Obwohl wir, wie wir eben beschrieben haben, leicht vorübergehende Veränderungen in einigen der System-Charakteristika durchführen können, wird wahrscheinlich der Wunsch nach einer dauerhaften Veränderung auftauchen. Es ist auch wahrscheinlich, daß Sie irgendwann System-Charakteristika verändern wollen, die nicht mit den Utility-Programmen verändert werden können, wie zum Beispiel die Größe der Systempuffer (RCP, FCP und NDR). Für sehr viele Anwender werden die Default System-Konfigurationen nicht völlig Ihren Vorstellungen entsprechen. Zum Beispiel wenn Sie eine Harddisk besitzen, wird der Standard NDR Puffer mit seiner Kapazität von 21 Namen manchmal nicht reichen und Sie werden die Kapazität auf 28, 42 oder sogar mehr Namens-Einträge erhöhen wollen. Wir schätzen uns glücklich, Ihnen mitteilen zu können, daß alle diese Dinge machbar sind, und noch dazu ziemlich einfach.
Die Charakteristika des NZ-COM-Systems sind definiert durch "Deskriptor"-Files in zwei alternativen Formaten, durch den Dateityp ZCM und den anderen vom Typ ENV. Dateien beider Typen werden durch das MKZCM-Utility (siehe Abschnitt 5.2.4). Sie können mit dem Format arbeiten, das Ihnen mehr zusagt; die andere Datei können Sie löschen, wenn Sie wollen.
Die ZCM-Dateien sind gewöhnliche Textfiles in Form einer Symboltabelle, die mit jedem x-beliebigen Text-Editor bearbeitet werden können (im NON-DOKUMENT Modus = ASCII).
An diesem Punkt empfehlen wir Ihnen, die Default Deskriptor-Dateien durch Eingabe von
TYPE NZCOM.ZCM<cr>
zu untersuchen.
Die ENV-Dateien sind Binär-Dateien in Form von Z-System "Environment-Deskriptoren". Sie können den Default ENV-Deskriptor untersuchen durch Eingabe des ARUNZ-Alias-Befehls:
LOOK NZCOM.ENV<cr>
Die Bildschirmanzeige wird Ihnen nicht viel sagen, es sei denn, Sie sind schon vertraut mit den Z-System Programmier-Interna. Der einzige Vorteil der ENV-Form ist, daß die Datei nur einen Record (128 Bytes) lang ist, wohingegen die ZCM-Datei fünf Records lang ist. Es gibt ein paar Gelegenheiten, wo eine ENV-Datei benötigt wird, um ein anderes Z-System-Programm zu installieren. Im allgemeinen empfehlen wir das Arbeiten mit der ZCM-Datei.
5.2.3 Modifizieren der Deskriptor-Dateien
Das System-Definitionen-Utility MKZCM kann Änderungen nur in der Speicher-Zuweisungstabelle machen; viele andere Charakteristika können durch Editieren der System-Deskriptor-Datei geändert werden. Einige dieser Änderungen sollten Sie durchführen zur Optimierung des System-Deskriptors mit den Charakteristika Ihrer Hardware. Es ist eine gute Idee, diese Änderungen anfangs in der Datei NZCOM.ZCM durchzuführen. Dadurch müssen Sie im allgemeinen keine weiteren Änderungen, außer durch Verwendung von MKZCM. 1 Einige Charakteristika, die Sie höchstwahrscheinlich ändern wollen, damit Sie zur Hardware passen, werden nachfolgend behandelt.
1Das hängt damit zusammen, daß MKZCM immer die Werte des aktiven Systems liest (wenn ein Z-System läuft) und diese Werte in die neue ZCM-Dateien und ENV-Dateien integriert.
Laufwerke und Userbereiche
Der Laufwerk Vector (DRVEC) ist ein 16-Bit Wort, das dem System mittteilt, welches logische Laufwerk zulässig ist. Das niederwertigste Bit entspricht Laufwerk A. Wenn Ihr Computer also über die Diskettenlaufwerke A und B, die Festplatten-Partitionen F, G, H, I und eine RAM-Disk M verfügt, sähe der Drive Vector in Binärform so aus:
Laufwerk: Bit:
In hexadezimaler Notation, wie es die ZCM-Datei erfordert, wäre dies 10F3 für dieses Beispiel. Der Defaultwert, den MKZCM von CP/M aus erzeugt ist FFFF (alle 16 CP/M-Laufwerke erlaubt).
Es gibt ein zweites Symbol, das das höchste logische Laufwerk in einem Z-System bestimmt. MAXDRV ist die Zahl des höchsten Laufwerks innerhalb des Systems, beginnend mit A=1. Im oberen Beispiel, würde dieses Symbol den Wert 13 dezimal oder 000D Hex erhalten. Der Defaultwert, den MKZCM von CP/M aus erzeugt ist 0010 (16 dezimal, alle Laufwerke erlaubt). 2
2Die meisten Utilities wissen nichts vom Drive Vector und verwenden MAXDRV um das anzusprechende Laufwerk zu erkennen. Ebenso gibt es Situationen, in denen man eine Unterscheidungsmöglichkeit braucht zwischen Laufwerken, die für benannte Directory-Referenzen erlaubt sind (Drive Vector) und dem höchsten Laufwerk, auf das ein User mittels der Drive/User (DU:)-Form in Bezug auf MAXDRV zugreifen darf).
Das Symbol MAXUSR spezifiziert die höchste Usernummer, die im Z-System erlaubt ist. Obwohl nur Userbereiche von 0 bis 15 eingeloggt werden können, weist CP/M-2.2 tatsächlich Dateien im Disk-Directory Usernummern 0 bis 31 zu. Daher ist der von MKZCM unter CP/M erzeugte Defaultwert 001F (31 dezimal), und es gibt selten Gründe, diesen Wert zu ändern.
Drucker und CRT Charakteristika
Das Z-System-Environment definiert einige physikalische Charakteristika von Drucker- und CRT-Devices. Vor ZCPR34 speicherte das Environment zwei CRT-Definitionen und vier Drucker-Definitionen. Die aktiven Definitionen wurden selektiert durch die Werte der Symbole CRT und PRT. Nun gibt es nur eine Definition für jedes Device (daher sollten die Symbole CRT und PRT nicht von ihrem Defaultwert 0000) abgeändert werden, aber das Utility CPSET kann benutzt werden, um eine beliebige Zahl von Definitionen zu erzeugen.
Die Default-Device-Charakteristika können durch die folgenden Symbole eingestellt werden:
System Laufzeit Charakteristika
Manche Z-System-Software Zeitschleifen basieren auf dem Wert des Symbols SPEED. Setzen Sie es auf die Taktfrequenz der CPU in Ihrem Computer, gerundet auf ganze Megahertz. Wenn Ihre Maschine auf 2,5 MHz getaktet ist, müssen Sie sich entscheiden, ob Sie lieber tiefstapeln (0002) oder übertreiben (0003); die Definition dieses Symbols gestattet keine "ehrliche" Angabe! Der Default Wert von MKZCM ist 0004.
Eine Zahl von Z-System-Utilities zeigen weniger oder gar keine Bildschirm-Information, wenn das System "Quiet Flag" gesetzt ist. Der Zustand dieses Flags beim Systemstart wird durch das Symbol QUIET bestimmt. Normalerweise ist sein Wert 0000 oder 0001 für "stille" Operation.
Z-System-Utilities und der Kommandoprozessor können Directory-Angaben der Form DU: erlauben oder zurückweisen. Wenn das Symbol DUOK auf den (Default-) Wert 0001 gesetzt ist, können Directories im Drive/User-Format eingegeben werden. Wenn der Wert 0000 ist, dann werden nur benannte Directories akzeptiert. Die letztere Möglichkeit wird selten benutzt und ist nicht zu empfehlen.
Public Directory Spezifikation
Man kann die initiale Konfiguration von ZRDOS Public Directories angeben, die die Symbole PUBDRV und PUBUSR verwenden. Die acht niederwertigsten Bits jedes Worts werden benutzt. Für PUBDRV repräsentiert das niederwertigste Bit (LSB-Bit 0) Laufwerk A und das höchste (Bit 7) Laufwerk H. Setzen Sie die Bits für jedes Laufwerk, das Sie beim Systemstart zum Public-Laufwerk erklären wollen. Für PUBUSR repräsentiert das niederwertigste Bit (Bit 0) User 1 und das höchste (Bit 7) User 8. Setzen Sie die Bits für jeden Userbereich, den Sie als Public definieren wollen. Die Defaultwerte sind 0000 für beide Symbole, so daß kein Verzeichnis von Haus aus "Public" ist.
5.2.4 Erzeugen neuer Definitionen mit MKZCM
Das Utility MKZCM stellt einen bequemen Weg dar, die Speicherzuordnung des Systems neu zu verteilen und völlig neue System-Deskriptoren zu beschreiben. Es erlaubt die Größenveränderung der System-Haupt-Moduln, einschließlich eines speziellen "User"-Puffers, der sehr gelegen kommen kann für Systemerweiterungen "oberhalb des BIOS", wie DateStamper oder RAM-Disks bzw. Festplatten-Laufwerke.
Sie können den Befehl
MKZCM //<cr>
wie gewohnt eingeben, um eine Hilfsseite mit Erklärung der Funktionen und Syntax von MKZCM zu erhalten. Aus der Hilfeseite, können Sie entweder zurück ins Betriebssystem, oder ins Programm gehen. Sie können auch jede der zwei folgenden Formen
MKZCM<cr> MKZCM name<cr>
eingeben, um direkt ins Programm zu gelangen:
In der zweiten Form ist "name" der Dateiname, der den ZCM- und ENV-Deskriptor-Dateien für die neudefinierten Systeme zugewiesen wird. In der ersten Form erscheint ein Prompt für einen Namen aus dem Programm heraus, wenn einer benötigt wird.
Wenn MKZCM läuft, präsentiert es ein Menü, das fast den gesamten Schirm ausfüllt und einen Prompt an der Fußzeile. Sie können auf zahlreiche Art antworten. Sie können jede der Zahlen (oder den Buchstaben "U") eingeben, die auf der linken Bildschirmseite erscheinen, um dasjenige System-Modul auszuwählen, dessen Größe Sie ändern möchten. In diesem Fall erscheint ein Prompt für einen neuen Wert der Modulgröße in Records (128 dezimal oder 80 hex). 3
3Die Definition des Shell Stacks ist eine Ausnahme. Einfach auf die Prompts antworten.
Die Spanne der akzeptierten Werte und der Wert, der bei einem simplen Return übernommen wird, ist abhängig vom zu definierenden Modul. Für viele der Moduln selektiert Return den Wert 0 (Null). Aufgrund des Zwangs, daß das BIOS immer am Anfang einer "page" (einem geradzahligen Vielfachen von 256 Bytes dezimal bzw. 100 HEX) beginnen muß, wird MKZCM manchmal automatisch einen zusätzlichen Record an ein Modul anfügt. Aus diesem Grund erscheint es zweckmäßig, sich von unten nach oben durch das Menü zu arbeiten.
Obwohl MKZCM es erlaubt, CPR- und DOS-Größen zu definieren, die nicht den CP/M-Standards entsprechen, empfehlen wir, daß der Durchschnittsuser die Moduln 1 bis 3 nicht verändern sollten. Fortgeschrittene User können interessante und nützliche Anwendungsfälle für Systeme mit größeren (oder kleineren) Kommandoprozessoren oder BDOS-Systemen finden.
Die Absicht beim Entwurf von NZ-COM war, daß der User einige verschiedene Systeme entwirft und das momentan passende jeweils lädt. Der nächste Abschnitt des Handbuchs befaßt sich damit, wie man zu gegebener Zeit von einem auf das andere System umschalten kann. Bevor wir auf dieses Thema kommen, möchten wir vorschlagen, einige Konfigurationen herzustellen, die Sie in Betracht ziehen sollten.
Reden wir zuerst über die "User's memory area" - den reservierbaren persönlichen Speicherpuffer des Anwenders. Als Beispiel, wollen wir beschreiben, wie man diesen Puffer nutzen könnte, um etwa DateStamper zu betreiben. 4 Die Version von DateStamper, die mit einem allgemeinen BDOS läuft, erfordert 10 Records TPA. Sie kann automatisch konfiguriert werden und lädt sich selbst unterhalb des CCP, aber diese Methode schützt den CCP vor Überschreiben und verbraucht so zusätzlich 2K Speicher. Es ist wesentlich effizienter, DateStamper oberhalb des BIOS abzulegen.
4Das ist eine BetriebsSystemerweiterung für CP/M-2.2, die Zeit- und Datumseinträge verwaltet, um den Zeitpunkt der Erstellung, des letzten Zugriffs und der letzten Änderung zu indizieren.
Beim echten BIOS wird das Verlagern des BIOS nach unten erforderlich, um Platz zu schaffen für für DateStamper. Mancher Anwender fühlt sich hierbei überfordert und es bedeutet, daß der für DateStamper verbrauchte Speicher nie für Anwenderprogramme zur Verfügung steht. Mit NZ-COM können Sie sich eine System Definition schaffen, die einen Puffer für DateStamper und besitzt und eine andere ohne dieses Puffer.
Jetzt sollten Sie MKZCM aufrufen und die Beispiele durcharbeieten. Beachten Sie die Adressen der verschiedenen System Moduln. Jetzt definieren Sie einen Puffer für DateStamper durch Eingabe von "U" beim Prompt aus MKZCM und dann geben Sie ein:
10<cr>
Beachten Sie, wie die Addressen für die System Moduln sich automatisch ändern, um Platz für den Puffer zu schaffen. An diesem Punkt sollten Sie die Start-Adresse des User-Puffers notieren. Dann beginnen wir die Prozedur für das Schaffen einer speziellen "über dem BIOS"-Version von DateStamper. 5 Dann können Sie DateStamper wie gewohnt laden. Sie sollten beachten, daß aber bei jedem Laden eines neuen NZ-COM-Systems das DOS und das BIOS neugeladen werden. Dadurch verlieren Sie die Einbindung von DateStamper und Sie müssen DateStamper neu starten. Dies kann automatisch erfolgen, indem man die Systeme durch Verwendung von Alias Scripts ändert (sehen Sie sich hierzu die Beispiele in ALIAS.CMD an). 6
5Siehe dazu auch das DateStamper Handbuch.
6Siehe Abschnitt 6.4.3 für weitere Möglichkeiten.
Manche allgemeine Wahl für die anderen Systemkomponenten könnte wie folgt aussehen.
Zum Beispiel kann man sowohl Systeme mit oder ohne IOP (Input-Output-Package = Ein-Ausgabe-Paket). Wenn man gewöhnlich ein IOP wie etwa das ausgezeichnete NuKey Tastatur-Macro IOP benützt, dann würde das Default-System einen IOP-Puffer beinhalten und die Definition ohne Puffer könnte etwa NOIOP heißen. Benützen Sie meist kein IOP, dann würde die Definition ohne IOP Puffer den Defaultnamen NZCOM (ZCM und ENV) erhalten und die Version mit IOP könnte WITHIOP heißen.
Manchmal sucht man krampfhaft nach Möglichkeiten, um Arbeitsspeicher zu gewinnen. Für solche Anlässe ist ein System zweckmässig, vielleicht heißt es SMALL, das sowohl das IOP und das RCP entfernt, die zwei größten Hilfsmoduln. Wenn die Speichernot größer wird, kann ein System (vielleicht heißt es MIN) sogar das FCP und/oder das NDR, das Register für die benannten Verzeichnisse, entfernen.
Während Sie Erfahrung mit NZ-COM sammeln, werden Sie Verständnis für die System Definitionen entwickeln, die sich am besten für Ihre Zwecke eignen. Wenn sich Ihre Bedürfnisse ändern, können Sie leicht neu beginnen und bestehende Systeme löschen, oder noch weitere zu schaffen. Sie können sogar temporäre Definitionen aus dem Stand erzeugen und in weniger als einer Minute laden.
5.3 Laden neuer Systeme
Bisher haben das Erzeugen neuer Systeme behandelt; wir haben nicht beschrieben, wie andere Systeme als das Default-System namens NZCOM geladen werden. Erinnern wir uns, daß das Default-System geladen wird, wenn man den Befehl
NZCOM<cr>
eingibt. Dieser Befehl verwendet den System-Deskriptor NZCOM.ZCM (nur die ZCM-Version). Er lädt den Code und andere Moduln, die es braucht, entweder aus der Library NZCOM.LBR oder aus individuellen Dateien, die entlang des Suchpfades liegen können.
Der Kommandoprozessor (CPR), das DOS, und das Spezial NZ-COM-BIOS werden geladen unter Verwendung der Default-Dateien NZCPR.ZRL, NZDOS.ZRL und NZBIO.ZRL, respektive. Zusätzlich werden der RCP, (NZRCP.ZRL), das FCP (NZFCP.ZRL) und das IOP (NZIOP.ZRL) geladen, wenn die betreffenden Moduln in der System-Definition vorgesehen sind. Das letztere ist nur ein "Dummy IOP", das die grundlegenden Zeichen- Ein- und Ausgabenfunktionen übernimmt. Werden benannte Directories unterstützt, wird eine Datei namens NZCOM.NDR geladen und, so vorhanden, die Terminal-Deskriptordatei NZCOM.Z3T ebenfalls.
Andere Systeme als die Default-Definition können auf vielfältige Art geladen werden. Zuerst, wollen wir eine Quickmethode beschreiben, die einfach anzuwenden ist und im allgemeinen das tut, was man erwartet. Bei dieser Methode verwenden wir die Befehlszeile:
NZCOM name<cr>
wobei "name" der Name einer ZCM- oder einer ENV-Datei ist, Sie mit MKZCM erzeugt haben. 7 Die System -Deskriptordatei dieses Namens wird benutzt, um das System zu definieren. Moduln werden genauso geladen, wie oben beschrieben.
7Oder eine ZCI-Datei, die von NZCOM erzeugt wurde, wie im nachfolgenden Abschnitt beschrieben wird.
Das Quick-Kommando kann nicht benutzt werden, um Systeme zu laden, die kleinere Moduln enthalten (abgesehen von Null-Files, die nur aus dem Namen bestehen). Zum Beispiel, wenn Sie ein System mit einem kleinen RCP definieren, (z. B. 10 Records), dann wird ein Fehler entstehen, wenn NZCOM versucht, NZRCP.ZRL zu laden, da der aus dieser Datei erzeugte RCP nicht in den für den RCP reservierten Puffer paßt. Daher sollte die Quickmethode nur zum Laden von Systemen verwendet werden, aus denen Puffer entweder vollständig ausgelassen wurden, oder in denen die Puffer zumindest die Standardgröße der Defaults aufweisen.
Die allgemeinste Form der Ladeanweisung für NZCOM erlaubt enorme Flexibilität, viel mehr, als die meisten Anwender je brauchen. Siehe hierzu Abschnitt 6.3.2 für vollständige Beschreibung. Jetzt werden wir lediglich die Befehlsform anmerken, die man zum Laden eines anderen als des Default-Systems verwenden sollte. Sie lautet:
NZCOM name modul(n)<cr>
wobei "name" wie zuvor, den Namen der Deskriptor-Datei bedeutet und wo ein oder mehrere System Moduln zum Laden explizit angegeben werden können. Zum Beispiel
NZCOM SMALL SMALLRCP.ZRL<cr>
würde ein System laden, das durch SMALL.ZCM (oder SMALL.ENV) beschrieben wurde und würde SMALLRCP.ZRL statt NZRCP.ZRL als RCP-Modul laden.
5.4 Clonen des Systems
Es gibt eine zusätzliche Methode, NZ-COM-Systeme zu laden, die den Vorteil größerer Ladegeschwindigkeit bietet, auf Kosten von Diskettenkapazität in Form größerer Dateien. NZCOM verfügt über eine "Clone"-Option, die die normale Systemerzeugungs-Prozedur (wie vom CP/M-Prompt) erlauben, aber mit dem Unterschied, daß das resultierende Environment in eine Datei geschrieben werden kann, statt es im Speicher zu installieren. Das Ergebnis ist eine Datei mit dem Namen der ZCM- oder ENV-Datei (oder NZCOM, wenn keiner angegeben wurde) vom Dateityp ZCI (für Z-Com Image). Zum Beispiel, erzeugt der Befehl
NZCOM /C<cr>
NZCOM.ZCI mit dem Default System Abbild (Image). Der Befehl
NZCOM SMALL SMALLRCP.ZRL /C<cr>
erzeugt SMALL.ZCI mit dem Abbild des Small Systems, einschließlich seines speziellen RCP-Moduls.
Systeme, die durch ZCI-Dateien definiert wurden, werden genauso geladen, wie jene, die durch ZCM- und ENV-Deskriptoren beschrieben wurden, durch hinzufügen ihrer Namen auf der NZCOM Befehlszeile. Zum Beispiel
NZCOM SMALL.ZCI<cr>
lädt das Small-System in einer einzigen Operation, ohne daß man all die individuellen Dateien suchen und laden muß, die beim Erzeugen des SMALL.ZCI. Dies erlaubt das Laden des Systems in wesentlicher kürzerer Zeit. Es bedeutet auch, daß man die zum Erzeugen notwendigen Moduln (z. B. SMALLRCP.ZRL) nicht weiter auf der Diskette benötigt.
Wenn die Kurzform des NZCOM-Ladebefehls wie etwa
NZCOM SMALL<cr>
benutzt wird, wird als erster zu ladender Dateityp für SMALL ZCI, dann ZCM und schließlich ENV. Der einfache Ladebefehl
NZCOM<cr>
ist jedoch ein Sonderfall und entspricht
NZCOM NZCOM.ZCM<cr>
Wenn Sie NZCOM.ZCI laden möchten, sollten Sie eine der folgenden Befehlsfolgen wählen:
NZCOM NZCOM.ZCI<cr> NZCOM NZCOM.LBR NZCOM<cr>
Die erste Form lädt nur eine ZCI-Datei; die zweite Form zwingt lediglich NZCOM, seine normale Hierarchie ZCI, ZCM und schließlich ENV einzuhalten.
5.5 Systemmodifikationen "im Flug"
Die vorangegangene Diskussion hat vielleicht den Eindruck vermittelt, daß Sie ein bestimmtes NZ-COM-System laden und dann für die Dauer der Sitzung damit leben müssen. Dies ist ganz und gar nicht der Fall. Im Gegenteil, eins der grundlegenden Design-Features von NZ-COM ist seine Fähigkeit, neue Versionen des Betriebssystems jederzeit nachzuladen, sogar inmitten einer Mehrfach-Kommandozeile.
5.5.1 Lade-Regeln
Wenn NZCOM vom CP/M-Befehlsprompt aus geladen wird ("Cold"), treten alle im Deskriptorfile angegebenen Werte in Kraft und alle System-Moduln werden geladen, wie oben beschrieben (siehe Abschnitt 5.3). Auf der anderen Seite, wenn NZCOM aus einem bereits aktiven NZ-COM-System aufgerufen wird ("Warm"), werden nur die echten Veränderungen geladen.
Zuerst wird die ganze System-Information mit Ausnahme der Addressen und Größen der System-Moduln bewahrt, wann immer möglich. Shells und Error Handler laufen im neuen System weiter; der Suchpfad, Werte in Anwender-Registern, System-Dateinamen, Drucker- und CRT-Charakteristika etc. ändern sich nicht. Der Inhalt der Mehrfach-Kommandozeile wird in das neue System hinübergerettet. Das bedeutet, daß neue Konfigurationen als Teil einer komplexen Befehlssequenz geladen werden können, sogar mit konditioneller Ausführung. 8 Das System kommt dabei kein bißchen aus dem Tritt!
8Vorausgesetzt natürlich, daß keine Prüfbedingungen abgearbeitet werden müssen, während ein System ohne FCP aktiv ist.
Zweitens werden die Inhalte der System Moduln (RCP, NDR etc.) nicht verändert, außer die Adresse des Moduls hat sich geändert oder die Größe des Moduls hat sich vermindert. Sogar die ausdrückliche Angabe eines Moduls auf der NZCOM-Befehlszeile wird das Laden nicht erzwingen; es wird nur geladen, wenn eine der eben genannten Bedingungen ein Laden erfordert. 9
9Sie können ein Laden erzwingen, durch Aufruf von NZCOM im Modul-Lademodus, siehe Abschnitt 6.3.2.
5.5.2 Warum Systeme wechseln?
Welche Gründe gibt es für das "fliegende" Wechseln des Systems? Gewöhnlich heißt der Grund Sepeicherbedarf. Gäbe es unbegrenzten Speicher, würde man die größte, leistungsfähigste Version von NZ-COM laden, die man kriegen kann und mit dieser ständig arbeiten. Im wirklichen Leben, besonders bei einem CP/M-System mit seinem 64K-Speicher, müssen Zugeständnisse gemacht werden.
Die meiste Zeit würde man wahrscheinlich eine recht leistungsfähige Version des Z-Systems bevorzugen, eine, die alle System-Eigenschaften besitzt mit vielleicht der einzigen Ausnahme eines I/O-Pakets (IOP). Es wird jedoch vorkommen, daß ein Anwenderprogramm mehr Speicher benötigt, als diese Konfiguration erlaubt. Dann wäre es besser, ein kleineres System zu laden. Entsprechend würde man, wenn das Standard-System kein IOP besitzt, ein größeres System laden.
Zum Beispiel nehmen wir an, wir hätten ein Anwenderprogramm namens "BIGPROG", das viel Speicher benötigt (vielleicht eine Datenbank?). Wir könnten dann den Befehl
NZCOM SMALL;BIGPROG ... ;NZCOM<cr>
eingeben. Diese Befehlszeile installiert erst das "Small" NZ-COM-System mit seiner größeren TPA. Dann wird das Programm BIGPROG aufgerufen und schließlich, nach Beendigung von BIGPROG, wird das Standard NZ-COM-System wieder geladen. Abgesehen von der Zeiteinbuße, die damit verbunden ist, gibt es keinen Grund, vom Anwenderprogramm nicht benötigte Z-System-Features abzulegen, während dieses läuft. 10 Im obigen Beispiel ist die leistungsfähige Version des Z-System zurück an Ort und Stelle, wenn der Prompt für den nächsten Befehl erscheint. Soweit der Anwender merkt, war es eigentlich immer da.
10Wenige Anwenderprogramme machen von Z-System-Features Gebrauch. WordStar Release 4 ist die Ausnahme unter den Anwendungen aus den größeren Softwarehäusern; es kann benannte Directories benutzen. In diesem Fall möchte man ein NZ-COM-System erzeugen, das lediglich einen NDR-Puffer enthält.
5.5.3 Automatisierung der Systemwechsel
Der Vorgang des Systemwechselns kann in verschiedenen Stufen automatisiert werden, indem man sich die Fähigkeiten des Z-Systems zunutze macht. Die System-Ladebefehle wie im Abschnitt 5.3 beschrieben, können alle als Aliase ausgeführt werden oder man schließt sie in ALIAS.CMD ein. Dann kann man in ein anders System, wie SMALL, wechseln durch die simple Befehlszeile:
SMALL<cr>
Die Automation kann auf Situationen ausgedehnt werden, wo bestimmte Programme bestimmte Versionen des NZ-COM-Systems erfordern. Nehmen wir zum Beispiel an , daß BIGPROG.COM im Verzeichnis BIGDIR: steht und daß wir es in BGPRG.COM umbenennen. Wenn wir die folgende Script-Definition in unsere ALIAS.CMD-Datei aufnehmen
BIGPROG nzcom small;bigdir:bgprg $*;nzcom
dann können wir unseren Befehl wie gewohnt eingeben:
BIGPROG FILENAME ...<cr>
Der Extended Command Processor ARUNZ erledigt das Umschalten für uns automatisch. Verzinktere Scripts könnten sogar prüfen, ob die TPA schon groß genug für unser System ist und nur dann das System wechseln, wenn nötig. Es gibt kaum eine Grenze, was Einfallsreichtum aus der Flexibilität von NZ-COM machen kann!
Hier sollten wir zwei wichtige Punkte erwähnen. Zuerst einmal ist NZCOM schlau genug, keine Lade-Operation auszuführen, wenn es erkennt, daß ein zu ladendes System sich vom gegenwärtigen nicht unterscheidet. Zum zweiten, wenn NZCOM beim Ladeversuch auf einen Fehler trifft, gibt es nicht einfach auf. Es gibt eine Fehlermeldung aus und weist auf die Art des Fehlers hin, dann erst ruft es den Error Handler auf. Auf diese Weise haben Sie Gelegenheit, irgendwelche Fehler zu korrigieren, bevor die Kommandozeile "weiterpflügt" und möglicherweise in eine Katastrophe (oder zumindest in große Unannehmlichkeiten) steuert.
5.5.4 Automatische Rückkehr zu CP/M
Unter bestimmten außergewöhnlichen Umständen muß ein Programm im normalen CP/M ablaufen. Zum Beispiel braucht man jedes einzelne Bit TPA, das man kriegen kann. Oder man muß ein Konfigurationsprogramm laufen lassen, das direkte BIOS-Modifikationen ausführt, indem es Adressen mit einem Offset vom Warmboot-Vektor verwendet. Da unter NZ-COM der Warmboot-Vektor auf das virtuelle BIOS von NZ-COM zeigt, würden solche Utilities nicht korrekt arbeiten.
Um eine Stapelverabeitung auszuführen, kann man SUBMIT verwenden, wobei das Z-System vollständig verlassen, unter dem puren CP/M ein Programm ausgeführt, und dann ins Z-System zurückgekehrt wird! Man muß jedoch sehr vorsichtig sein. Zum Beispiel muß man offensichtlich darauf achten, daß alle Kommandozeilen, die dann ausgeführt werden sollen, wenn das Z-System nicht in Betrieb ist, gültige CP/M-Befehle sind. Das bedeutet, nur ein Befehl pro Zeile und keine type-3 oder type-4 Programme. Wenn der Stapel-Script das Z-System wieder geladen hat, können wieder angemessene Z-System-Befehle, einschließlich Mehrfach-Kommandozeilen verwendet werden.
Ein weiterer Faktor, den man berücksichtigen sollte, ist, daß das NZCPM Sie im CP/M auf Laufwerk A User 0 zurückliefert, egal von wo es gestartet wurde. Da ZCPR3 (beginnend mit Version 3.3) seine SUBMIT-Datei ins Verzeichnis A0: statt ins aktuelle schreibt, gibt es normalerweise kein Problem bei der durchgehenden Abarbeitung unter CP/M. 11 Wenn Sie NZ-COM wieder laden, (es ist ein Cold-Load, einschließlich Ausführung von STARTZCM), werden Sie nicht automatisch im ursprünglichen Directory landen. Sie müssen schon einen expliziten Befehl eingeben, um zurückzukehren.
11Wenn das Bezugslaufwerk durch BIOS-"Verbiegung" verändert wurde, können hier Probleme auftauchen. In diesem Fall kontakten Sie bitte Ihren Z-System Händler
Sie müssen außerdem sichergehen, daß Sie nur Versionen des ZCPR34 verwenden, die die Standard-SUBMIT-Verarbeitung unterstützen. Die Form "LONGSUB" der SUBMIT-Bearbeitung ist inkompatibel mit der SUBMIT-Bearbeitung von CP/M.
Hier ist eine Sequenz von Befehlszeilen, die in einer Datei namens CONFIG.SUB stehen könnte, um den automatischen Abkauf eines Utilities zu gewährleisten, das ursprünglich unter CP/M CONFIG.COM hieß:
A0:NZCPM CONFIG0 NZCOM $1:
Die erste Befehlszeile entfernt NZ-COM und restauriert CP/M auf User A0:. Die nächsten zwei Befehlszeilen laufen unter CP/M ab. Die erste ruft das Konfigurations-Utility auf, das wir in CONFIG0.COM umbenannt haben, die Gründe dafür werden wir gleich erläutern. Der zweite CP/M Befehl lädt die Standard Konfiguration von NZ-COM. Nach Beendigung des Befehls läuft das Z-System wieder, wir befinden uns aber noch immer im Verzeichnis A0:. Die letzte Zeile läuft im Z-System ab und ist dazu gedacht, uns in das Directory zurückzubringen, von wo wir gestartet waren.
Der Ausdruck "$1" im letzten Befehl ist ein SUBMIT-Parameter. Wir haben angenommen, daß dieser SUBMIT-Script durch einen Alias namens CONFIG in der Datei ALIAS.CMD ausgeführt wird. Der Alias-Script müßte die Form besitzen:
CONFIG sub config $hb
Der ARUNZ-Parameter "$hb" gibt uns das Ursprungs-Directory zurück, wenn der Alias in der Form "DU" aufgerufen wird. Dies wird als Parameter an den SUBMIT-Job übergeben.