Next: Die Systemaufrufe
Up: L3 Referenzhandbuch
Previous: L3DOS
L3 kennt als systemglobale Teile ausschließlich Prozesse. Es gibt bekanntlich
zwei Typen von Prozessen in einem L3 System:
- Realprozesse. Sie sind dem Systemkern zuzuordnen. Beispiele für Realprozesse
sind z.B. Treiber für Bildschirm und Tastatur. Jedes Gerät, wie das Diskettenlaufwerk oder irgendeine Erweiterungskarte wird als Prozeß aufgefaßt. Das Gerät
kann demzufolge durch einen internen Namen, einen Taskbezeichner identifiziert und adressiert werden. Realprozesse sind resident, sie unterliegen nicht dem
Paging. Sie werden beim Anschalten des Systems gestartet und beim Abschalten
beendet.
- Virtuelle Prozesse. Sie gehören zur Systemschale. Ihre Aufgabe und Ausformung
ist unterschiedlich. Beispielsweise sind alle benutzereigenen Tasks, also die
Arbeitsumgebungen, virtuelle Prozesse. Auch bestimmte, für das Funktionieren
des Systems unverzichtbare Tasks, wie z.B. SYSIO sind virtuelle Prozesse. Sie
können jederzeit angelegt und beendet werden, ihre Lebensdauer ist jedoch nicht
beschränkt, da sie dem Paging unterliegen.
Zwischen den verschiedenen Prozessen ist Kommunikation in vielfältiger Ausprägung
nötig: Das Anlegen einer neuen Task erfolgt durch Senden eines Auftragscodes an den
SUPERVISOR. Jede Bildschirmausgabe eines Anwendungsprogramms kommt durch
Sendung der auszugebenden Zeichen von der Task an den zugeordneten Bildschirmtreiber zustande. Kommunikation findet bei L3 stets durch Übertragung einer
Botschaft von einem Sender an einen Empfänger statt. Eine Botschaft ist ein
Meldungscode, ein Auftragscode (eine Bitte) oder ein Objekt (z.B. ein Text oder eine
Datei). Die Kommunikation ist synchron, d.h. der Empfänger muß empfangsbereit
und -willig sein, bevor der Sender seine Botschaft überstellen kann. Natürlich kann
ein Sender probeweise senden; falls sein Adressat jedoch nicht bereit ist, passiert
nichts. Desweiteren gilt, daß ein Empfänger nach Erhalt einer Botschaft frei in seiner
Reaktion ist. Es werden also nur solche Botschaften eine Reaktion des Empfängers
hervorrufen, die den Anforderungen des Empfängers genügen. Kein Empfänger kann
gezwungen werden, gegen seinen Willen zu handeln. Sicherheit, Eindeutigkeit und
Effizienz der Botschaften wird durch Absprachen über die Gestalt und den Inhalt der
Botschaften zwischen den beteiligten (Prozessen) erreicht. Solche Absprachen nennt
man Protokoll.
L3 kennt eine Reihe von definierten Protokollen zur Unterstützung der
L3-typischen Kommunikationsanforderungen.
- General Driver Protocol (GDP)
-
Das allgemeine Treiber Protokoll
Es beschreibt die Kommunikation zwischen Treiberprozessen und ihren
Partnern. Es unterstützt die Realisierung der Basisfunktionen von L3.
- Supervisor Protokoll
-
Es beschreibt die Kommunikation zwischen der Task SUPERVISOR und allen
anderen Tasks. Mit Hilfe dieses Protokolls werden die globalen Objekte eines
L3 Systems, die Tasks verwaltet.
- Link Protokoll
-
Es beschreibt die Kommunikation zwischen den Terminaltasks und anderen
Tasks. Es dient somit vor allem zur Steuerung der Interaktion.
- Dateimanager Protokoll
-
Es beschreibt die Kommunikation zwischen einer als Dateimanager ausgewiesenen Task und ihren Klienten. Es liefert somit Grundfunktionen für die Erfordernisse der Multiuser Betriebs.
All diese Protokolle weisen eine gemeinsame Grundstruktur auf, die ihre Gestalt aus
dem Aufbau von Botschaften in L3 gewinnt.
Für jedes Protokoll gilt, daß eine Botschaft stets mit einem Botschaftsabschnitt des
Typs Integer beginnt. Diese Zahl ist eine Kennziffer zum Auftakt der Botschaft und
setzt sich aus der Codierung des Protokolltyps und einer für diesen Protokolltyp
definierten Funktion zusammen. Weitere Botschaftsabschnitte enthalten dann gegebenenfalls weitere Objekte, die als Funktionsparameter zu betrachten sind.
Ausschlaggebend ist jedoch, daß der Empfänger einer Botschaft bereits am ersten
(Integer) Abschnitt der Botschaft sicher identifizieren kann, ob er generell als
Empfänger in Betracht kommt und ob er eine geforderte Leistung erbringen kann.
Protokolle bieten also Sicherheits- und Effizienzgewinn.
Allen Protokollen gemeinsam ist ein Integerabschnitt als erste Botschaft. Das erste
Byte liefert dabei die Protokollidentifikation. Die Bedeutung der weiteren 3 Byte
dieser Codierung ist abhängig vom jeweiligen Protokoll.
Die Codierungen von 0x00000000 bis 0x3fffffff sind also vollständig für L3 Systemfunktionen reserviert. Falls Sie bei Erstellung irgendwelcher Anwendungen also ein
eigenes Protokoll definieren möchten, wählen Sie eine Codierung ab 0x40000000.
Das General Driver Protocol (GDP, allgemeines Treiber Protokoll) beschreibt die
Kommunikation zwischen einem Prozeß, der als Treiber eines Geräts (z.B. Diskettenlaufwerk) dient, und seinem virtuellen Initiatorprozeß (z.B. der Task ARCHIVE A).
Diese Realprozesse bewerkstelligen die Kommunikation zwischen virtueller Systemwelt (Task) und Realwelt (Hardware).
GDP
Realwelt <--> Realprozeß <--> Systemwelt
Benutzer <--> Tastatur <--> Task
Treiberprozesse sind direkt an den L3 Systemkern angelehnt. Sie haben
unbeschränkte Ein-/Ausgabe-Privilegien. Jeder Baustein in der Peripherie eines
386ers der der Ein-/Ausgabe dient, hat einen zugehörigen Treiberprozeß. Treiberprozesse können von privilegierten Benutzern ersetzt und das Gesamtsystem kann
durch weitere Treiberprozesse ergänzt werden, wenn neue Geräte in den Rechner
eingebaut werden.
Diktion:
Ein Gerät ist eine Baugruppe mit eigener Funktionalität und eigener
Programmierschnittstelle in der Peripherie eines 386er Rechners. Zum
Beispiel ist ein 8272 Diskettencontroller mit allen angeschlossenen Laufwerken ein Gerät im Sinne dieser Beschreibung, da der 8272 die angeschlossenen Laufwerke nicht unabhängig voneinander steuert.
Desgleichen sind auch Grafikkarten, Terminalemulationskarten etc.
Geräte.
Das allgemeine Treiberprotokoll beschreibt nun die Gestalt von Botschaften, die
zwischen virtuellen Prozessen und Treibern gesendet und empfangen werden. Die
Aufgabe eines Treibers ist die korrekte und effektive Umsetzung der Aufträge in
Aktionen des von ihm getriebenen Geräts.
Die folgenden Ausführungen beschreiben also zum einen für den Programmierer, der
aus einem virtuellen Prozeß heraus Leistungen eines Realprozesses nutzen möchten,
welche Botschaften er formulieren kann und muß. Zum anderen gibt dieser
Abschnitt auch die Leistungen vor, die ein Treiber für ein Gerät innerhalb des
L3 Systems erbringen muß.
Alle GDP Botschaften haben den Protokolltyp 01. Ein Botschaftsvektor, der eine GDP
Botschaft enthält, beginnt mit einer Zahl, deren erstes Byte (das High Byte, Bit 24 bis
31) eine 1 enthält. Desweiteren sind ein eventuell vorhandener Kanal, der Objekttyp und die Funktion codiert.
31 ......... 24 23 ............. 16 15 ...................... 4 3 2 1 0
Typ 01 Kanal Objekttyp Funktion
Kanäle sind dort vorhanden, wo ein Treiber Aufträge an weitere Treiber verteilt oder
mehrere Geräte bedient. Ein Beispiel ist wiederum der Diskettencontroller 8272, der
bis zu 4 Disketten- und/oder Streamerlaufwerke steuern kann. Das einzige Gerät aus
L3 Sicht ist der Contoller. Er steuert alle physisch vorhandenen Laufwerke.
Task GDP Auftrag Kanal Phys.Gerät
ARCHIVE A LAUFWERK 1
ARCHIVE B --> 8272 CONTROLLER PROCESS --> LAUFWERK 2
Der Objekttyp spezifiziert die angesprochene Geräteklasse. Da nur bestimmte Operationen auf den jeweils adressierten Gerät sinnvoll sind, sind die möglichen Parameter
durch den Objekttyp, also die Art des Gerätes und die Funktion vorbestimmt.
Die Funktion beschreibt die Leistung, die erbracht werden soll. Auf der Auftraggeberseite werden auf diese Weise die verschiedenen möglichen Ein-/Ausgabeoperationen
beschrieben. Auf der Seite des Auftragnehmers (Treibers) wird entsprechend die
Antwort formuliert.
Wie oben beschrieben, enthält eine GDP Botschaft grundsätzlich als erste Komponente eine Zahl, die eine vollständige Auftragscodierung darstellt. Die Zahl enthält
codierte Information über die GDP Funktion, den Typ der angesprochenen Objekte,
sowie ggf. die Angabe des angesprochenen Unterkanals.
Aufbau der Botschaft
31 ......... 24 23 ............. 16 15 ..................... 4 3 2 1 0
Typ 01 Kanal Objekttyp Funktion
Wertebereiche und Bedeutung:
- 01:
- Feste Kennung für GDP Botschaften.
- Kanal:
- 0 bis 0xff. Ein Gerät kann bis zu 256 logische oder physische
»Unter«geräte umfassen. Die Adressierung des gewünschten
»Untergerätes« - z.B. eines von mehreren an den Diskettencontroller angeschlossenen Laufwerken - erfolgt durch die Angabe
des ihm zugeordneten Kanals. Voreinstellung ist der Kanal 0.
- Objekttyp:
- 0 bis 0xfff. Das GDP teilt die diversen möglichen Geräte in
verschiedene Klassen und Unterklassen ein. Die Realisierung der
geforderten Funktion enthält nur in Zusammenhang mit der
angegebenen Geräteklasse eine Bedeutung, da sich z.B. die
Aufforderung an den Treiber »Führe eine Ausgabe durch« bei
Disketten- und Bildschirmtreibern deutlich unterscheidet.
- Funktion:
- 0 bis 0xf. Elementarfunktionen eines Treibers.
In der Version 1 des Betriebssystems L3 werden Kanäle z.B. innerhalb des
Treiberprozesses für das Diskettenlaufwerk benutzt. Das erste Diskettenlaufwerk wird
unter Kanal 0, das zweite unter Kanal 1 adressiert.
Die Botschaften zwischen Auftraggeber und Treiber sind im Prinzip von der Gestalt
»nimm diese Daten und führe den Auftrag aus«. Sie sind in folgende Funktionen
untergliedert:
reply
- Code: 0x01 xx xx x0
- Wirkung: Die Ausführung eines Auftrags oder die Anfrage nach einer durchführbaren Operation wird durch reply beantwortet.
Zur Antwort reply gehört gegebenenfalls der Inhalt der Antwort.
Der Aufbau des Antwortinhalts ist in der Objekttyptabelle für die
jeweiligen Objekte angegeben.
alternate in order requested
- Code: 0x01 xx xx x4
alternate out order requested
- Code: 0x01 xx xx x5
- Wirkung: Falls ein Treiber einen Auftrag oder eine Anfrage erhält, die für
ihn nicht ausführbar ist, fordert er eine Alternative an, die für ihn
durchführbar ist. Er liefert einen für ihn eher durchführbaren
GDP-Auftrag zurück.
in order
- Code: 0x01 xx xx x8
- Wirkung: Damit wird ein Treiber aufgefordert Daten oder Statusinformationen an den Auftraggeber zu senden. Der Treiber schickt sein
reply nach Ausführung des Auftrags (synchron).
out order
- Code: 0x01 xx xx x9
- Wirkung: Dem Treiber werden Daten für eine Ausgabe oder Statusinformationen zugestellt. Der Treiber schickt sein reply nach Ausführung
des Auftrags (synchron).
early in order
- Code: 0x01 xx xx xA
- Wirkung: Der Treiber erhält den Auftrag, Daten oder Statusinformationen an
den Auftraggeber zu senden. Im Gegensatz zur in order ist dem
Treiber jedoch freigestellt, den Auftrag sofort auszuführen oder
asynchron zu antworten. Dafür stehen je nach Art des Treibers
folgende Möglichkeiten zur Verfügung:
-
Treiber mit voller Eigenkontrolle.
Dieses sind solche Treiber, die keinen Kontakt zur Außenwelt
haben, wie Diskette, Band oder Plattentreiber. Ein solcher
Treiber gibt statt eines reply mit den geforderten Daten
zunächst reply mit einer Wartezeit zurück. Dann leitet er die
Maßnahmen ein, um die zu liefernden Daten zu gewinnen, z.B.
Band starten. Nach Ablauf der Wartezeit erhält der Treiber die
nächste early in order, die dieselben Daten betrifft. Nun kann
er diese liefern oder aber erneut eine Wartezeit vorschlagen.
-
Treiber ohne volle Eigenkontrolle.
Dieses sind solche Treiber, die Kontakt zur Außenwelt haben,
wie Tastatur, RS232 oder LAN Empfangsmodule. Da ein solcher
Treiber nicht entscheiden kann, ob er nach Ablauf irgendeiner
Zeitspanne Daten hat, muß er entweder sofort vorhandene
Daten senden (wie in order ) der eine leere Antwort reply-nil
object geben.
early out order
- Code: 0x01 xx xx xB
- Wirkung: Der Treiber kann die übergebenen Daten entweder sofort (wie out
order) oder aber zunächst eine Antwort early ack ausgeben und
die Ausgabeoperation danach vornehmen (asynchron).
- Bemerkung: Falls early ack geantwortet wurde, kann natürlich bei der nachfolgenden Ausgabe ein Schreibfehler auftreten. In diesem Fall wird
beim nächsten Auftrag eine Fehlerantwort error status gegeben.
Diese Fehlerantwort kann sich auf mehr als die letzte Ausgabe
beziehen. Es sind dann alle Operationen, die seit der letzten
synchronen Operation durchgeführt wurden, als fehlerhaft zu
betrachten.
interrogate in order
- Code: 0x01 xx xx xC
interrogate out order
- Code: 0x01 xx xx xD
- Wirkung: Anfrage an den Treiber, ob er die spezifizierte Operation ausführen kann, und - wenn nein - welche Alternative er anbieten kann.
Es werden keine Daten gelesen oder geschrieben. Der Zustand des
Treibers bleibt unverändert.
Geräte und damit auch der Funktionsumfang ihrer Treiber werden durch ihren
Objekttyp beschrieben. Dieser Objekttyp setzt zusammen mit der Funktion fest, wie
die GDP Botschaft insgesamt aufgebaut sein muß.
Die Objekttypen sind hierarchisch gegliedert:
11 8 7 4 3 0
Geräteklasse Objektgruppe Index
Eine vollständige GDP Botschaft besteht aus der GDP Codierung, die das
angesprochene Objekt und die gewünschte Funktion spezifiziert, sowie weiteren
Datenobjekten, die als GDP Funktionsparameter betrachtet werden können.
Dabei spielt natürlich eine Rolle, ob die Botschaft in Zusammenhang mit einer in
order oder out order oder als reply gesendet wird.
Dieser Abschnitt beschreibt die für die verschiedenen Geräteklassen (GDP Objekte)
nötigen und möglichen Parametrisierungen.
Im folgenden erscheint diese Kennzeichnung:
- IN:
- Repräsentation der Botschaft bei in order, early in order, interrogate in
order, alternate in order requested.
- OUT:
- Repräsentation der Botschaft bei out order, early out order, interrogate
out order, alternate out order requested.
- RP:
- Repräsentation der Botschaft bei reply.
Bei der Spezifikation der Parameter ist eine ELAN-artige Schreibweise gewählt.
Falls eine Botschaft nur aus dem Integer Abschnitt -- also dem GDP Auftrag selbst --
besteht, wird der leere Rest der Botschaft durch '-' beschrieben.
Nullobjekt
- Code: 0x000
- Parameter: RP : -
- Wirkung: Bezeichnet den Typ »kein Objekt«. Es wird für einfache
(»acknowledge«) Antworten verwendet, die keine weiteren Objekte
benötigen.
Wartezeit
- Code: 0x001
- Parameter: RP : INT wartezeit
- Wirkung: Diese Antwort des Treibers kann nur auf eine early in order
folgen. 'wartezeit' ist eine Angabe in Millisekunden. Nach dieser
Zeit sollte noch einmal versucht werden, die Operation auszuführen.
Bytestring
- Code: 0x100
- Parameter: OUT/RP : ROW n BYTE string
IN : INT max stringlength
- Wirkung: Die Bytes sind Zeichen innerhalb eines sequentiellen Bytestroms.
Sie bilden jedoch kein zusammenhängendes Objekt mit fester
Bedeutung. Sie können somit vom Treiber in kleinere Stücke
geteilt oder mit anderen Bytestrings zusammengekoppelt werden,
ohne daß sich die Semantik des Bytestrings ändert.
Datagram
- Code: 0x101
- Parameter: OUT : ROW n BYTE string
IN : INT max stringlength
- Wirkung: Ein Datagramm ist ein Bytestrom, der ein abgeschlossenes Objekt
darstellt. Datagramme müssen als unteilbare Objekte behandelt
werden.
RS 232 Übertragungsmodus
- Code: 0x110
- Parameter: OUT/RP : INT baud, databits, stopbits, parity
IN : -
- Wirkung: Die Angaben übermitteln einem Treiber für eine serielle Schnittstelle die gewünschte neue Einstellung für Übertragungsrate und
-Modus.
RS 232 Kontrolle
- Code: 0x111
- Parameter: OUT/RP : INT line mask bits, line value bits
IN : -
- Wirkung: Für eine RS 232 Schnittstellen werden eine Leitungsmaske und
eine Wertemaske festgelegt. Die Numerierung der Leitungen ergibt
sich aus RS 232. (Bit 2 = Leitung 2 usw. Achtung, die Numerierung der Bits in einen Doppelwort ist 0 bis 31, die der
Leitungen 1 bis 25!)
Die Leitungsmaske gibt an, welche Leitungen beachtlich sind, die
Wertemaske gibt die gewünschte Polarität an. Es gilt:
line mask bits AND line value bits
legt Leitungen mit 1 Polarität fest,
line mask bits AND NOT line value bits
legt Leitungen mit 0 Polarität fest.
- Beispiel: LET line mask bits = 0x00 10 00 00,
line value bits = 0x00 10 00 00,
control line out = 0x01 00 11 19;
Diese Botschaft setzt Leitung 21 auf 1-Polarität
Blocksequenz
- Code: 0x200
- Parameter: OUT/RP : INT blockno, ROW blocklength BYTE blocks
IN : INT blockno, INT blocklength
- Wirkung: Blöcke sind der Grunddatentyp für Geräte, die auf magnetischen
Speichermedien basieren (Disketten, Bänder..). 'blocklength'
muß die in Transfer Modus eingestellte Blockgröße oder ein
Vielfaches davon sein.
Transfer Modus Diskette
- Code: 0x210
- Parameter: OUT/RP : INT blockno, sectors per track, sector size
IN : -
- Wirkung: Einstellung der Laufwerksparameter.
Diskettenformat
- Code: 0x211
- Parameter: OUT/RP : INT formatcode
IN :
- Wirkung: Akzeptierte Formate sind:
0 : undefiniert
1 : 3,5" oder 5,25" Diskette, DS, SD
2 : 3,5" oder 5,25" Diskette, DS, DD
3 : 5,25" Diskette, DS, HD
4 : 3,5" Diskette, DS, HD
Wenn bei einer out Operation der Wert »undefiniert« an den
Treiber geschickt wird, so soll der Treiber das Diskettenformat der
Diskette im Laufwerk bestimmen und als Einstellung annehmen.
Falls das gelingt, sendet er ack nil. Der Formattyp kann dann
durch eine in Botschaft erfragt werden.
Falls der Treiber den Formattyp nicht bestimmen kann, weil z.B.
keine Diskette im Laufwerk ist, so sendet er alternate out
request.
Scancode, Taste
- Code: 0x300
- Parameter:
Scancodes, Tasten
- Code: 0x301
- Parameter:
Shiftstatus
- Code: 0x302
- Parameter:
HotKey
- Code: 0x304
- Parameter:
Attribut, Zeichenkette
- Code: 0x400
- Parameter: OUT : INT x, y, attr, ROW n BYTE chars
- Wirkung: Die Bytefolge 'chars' wird an der Position 'x','y' ausgegeben. Die
Farbdarstellung aller Zeichen wird durch 'attr' bestimmt (siehe
Kap.5: set attribute). Der Cursor wird nicht mitgeführt, bleibt also
an der Position, die er vor der Ausgabe von 'chars' hatte.
Falls 'chars' »zu lang« ist, also 'x' + 'n' (LENGTH(chars)) >
'width' (siehe Bildschirmeinstellung), wird die Ausgabe abgeschnitten.
Attribut, Zeichenkette + Cursor
- Code: 0x401
- Parameter: OUT : INT x, y, attr, ROW n BYTE chars
- Wirkung: Die Bytefolge 'chars' wird ab der Position 'x','y' ausgegeben. Die
Farbdarstellung für alle Zeichen wird durch 'attr' bestimmt. Der
Cursor wird mitgeführt. Er steht nach der Ausgabe hinter dem
letzten Zeichen von 'chars', oder falls dieses Zeichen am Bildschirmrand (meistens x-Position 79) steht, auf dem letzten
Zeichen von 'chars'.
Falls 'chars' »zu lang« ist, also 'x' + 'n' (LENGTH(chars)) >
'width' (siehe Bildschirmeinstellung), wird die Ausgabe abgeschnitten.
(Attribut + Zeichen)kette
- Code: 0x402
- Parameter: OUT : INT x, y, ROW n BYTE char, attr
- Wirkung: Die Bytefolge 'chars' wird an der Position 'x','y' ausgegeben. Die
Farbdarstellung jedes Zeichens 'char' wird durch das nachfolgende Byte 'attr' bestimmt Der Cursor wird nicht mitgeführt,
bleibt also an der Position, die er vor der Ausgabe hatte.
Falls 'chars' »zu lang« ist, also 'x' + ('n' DIV 2)
(LENGTH(chars)) > 'width' (siehe Bildschirmeinstellung), wird
die Ausgabe abgeschnitten.
(Attribut + Zeichen)kette + Cursor
- Code: 0x403
- Parameter: OUT : INT x, y, ROW n BYTE char, attr
- Wirkung: Die Bytefolge 'chars' wird an der Position 'x','y' ausgegeben. Die
Farbdarstellung jedes Zeichens 'char' wird durch das nachfolgende Byte 'attr' bestimmt Der Cursor wird mitgeführt. Er steht
nach der Ausgabe hinter dem letzten Zeichen 'char', oder falls
dieses Zeichen am Bildschirmrand (meistens x-Position 79) steht,
auf dem letzten Zeichen 'char'.
Falls 'chars' »zu lang« ist, also 'x' + ('n' DIV 2)
(LENGTH(chars)) > 'width' (siehe Bildschirmeinstellung), wird
die Ausgabe abgeschnitten.
Fenster füllen
- Code: 0x404
- Parameter: OUT : INT leftx, lefty, width, height, fillchar
- Wirkung: Das durch die »linke obere Ecke« 'leftx', 'lefty', seine Breite
'width' und seine Höhe 'height' beschriebene Fenster wird mit
dem Zeichen 'fillchar' gefüllt, ohne das Attribut zu ändern.
Fenster scrollen
- Code: 0x405
- Parameter: OUT : INT leftx, lefty, width, depth,
scroll lines, fillchar, fillattr
- Wirkung: Das durch die »linke obere Ecke« 'leftx', 'lefty', seine Breite
'width' und seine Tiefe 'depth' beschriebene Fenster wird um
'scroll lines' gescrollt. Ein positiver Wert für 'scroll lines'
verschiebt den Inhalt des Fensters nach oben. Ein negativer Wert
verschiebt nach unten. Das durch Scrolling freiwerdende Fenster
wird mit Zeichen 'fillchar' in der Farbdarstellung 'fillattr' gefüllt.
Dieses Protokoll beschreibt Botschaften zur und von der Task SUPERVISOR.
SUPERVISOR ist Verwalter des Tasksystems. Jede Änderung des Systems - wie Löschen
oder Neueinrichten einer Task oder Information über das Tasksystem - läuft durch
und über den SUPERVISOR ab. Der SUPERVISOR ist die einzige Instanz in einem
L3 System, die die internen Prozeßbezeichner kennt. Voraussetzung zur
Intertask Kommunikation ist gerade die Kenntnis dieser internen, eindeutigen
Namen. Alle in diesem Abschnitt beschriebenen Leistungen stehen in Form von ELAN
Prozeduren im ELAN System des Betriebssystems L3 zur Verfügung. Sollen
Aktionen, deren Wirkung nicht auf eine Task beschränkt ist, in anderen Programmiersystemen verfügbar sein, so müssen die notwendigen internen Informationen
über Prozeßbezeichner zunächst von der Task SUPERVISOR beschafft werden. Der
SUPERVISOR hat jedoch nur Kenntnisse über die virtuellen Prozesse eines L3
Systems. Die internen Prozeßbezeichner von Realprozessen (Treiberprozessen)
müssen mit Hilfe des Systemcalls Nummer 17 (sys prc id) geholt werden.
begin
- Code: 0x02 00 00 10
- Parameter: TEXT taskname
INT startaddr
DATASPACE stdds
- Wirkung: Eine neue Task wird angelegt. Der externe Name ist 'taskname'.
Die Task erhält den Datenraum 'stdds' als Standarddatenraum.
Der Befehlszähler für die Task zeigt auf die Adresse 'startaddr' im
Standarddatenraum.
rename
- Code: 0x02 00 00 11
- Parameter: TEXT new taskname
- Wirkung: Die Task, die dem SUPERVISOR diesen Auftrag schickt, erhält den
Namen 'new taskname'. Mit dieser Umbenennung erhält die Task
auch eine neue Versionsnummer! Der alte interne Prozeßbezeichner bezeichnet dann keine existierende Task mehr. Ein
send- oder call-Befehl irgendeiner anderen Task, der noch den
alten Prozeßbezeichner -- der vor 'rename' galt -- benutzt, liefert
dann den Antwortcode 1 : 'task not existing'.
end
- Code: 0x02 00 00 12
- Parameter: TASK task
- Wirkung: Der virtuelle Prozeß 'task' wird gelöscht. Damit sind auch alle
Datenräume der Task gelöscht und alle Tasks, die Nachkommen
der gelöschten Task sind.
- Bemerkung: Ein 'end' Auftrag wird vom SUPERVISOR nur akzeptiert, falls er
-
von der zu löschenden Task selbst kommt,
-
von einer Task die Vorfahre der zu löschenden ist, gegeben
wird,
-
von einer Task aus dem Systemzweig kommt und nicht eine
Task aus dem Systemzweig betrifft, die dem Auftraggeber
übergeordnet ist.
halt
- Code: 0x02 00 00 13
- Parameter: TASK task
- Wirkung: Dem virtuellen Prozeß 'task' wird die Fehlermeldung 'halt from
terminal' zugestellt.
- Bemerkung: Ein 'halt' Auftrag wird vom SUPERVISOR nur akzeptiert, falls er
-
von einer Task, die Vorfahre der zu löschenden ist, gegeben
wird,
-
von einer Task aus dem Systemzweig kommt und nicht eine
Task aus dem Systemzweig betrifft, die dem Auftraggeber
übergeordnet ist.
system catalogue
- Code: 0x02 00 00 20
- Parameter: TASK task
- liefert: DATASPACE system catalog
- Wirkung: Die Task SUPERVISOR schickt den aktuellen Systemkatalog an die
anfordernde Task.
father
- Code: 0x02 00 00 21
- Parameter: TASK task
- liefert: TASK vatertask
- Wirkung: Die Task SUPERVISOR liefert den internen Taskbezeichner der
Task, die unmittelbarer Vorfahre (Vatertask) von 'task' ist.
son
- Code: 0x02 00 00 22
- Parameter: TASK task
- liefert: TASK sontask
- Wirkung: Die Task SUPERVISOR liefert den internen Taskbezeichner der
Task, die unmittelbarer Nachkomme (Sohntask) von 'task' ist.
Falls mehrere Nachkommen existieren, wird der zuletzt angelegte geliefert.
Falls keine derartige Task existiert, wird 'niltask' geliefert.
brother
- Code: 0x02 00 00 23
- Parameter: TASK task
- liefert: TASK brothertask
- Wirkung: Die Task SUPERVISOR liefert den internen Taskbezeichner der
Task, die als nächstältere Sohntask unter der Vatertask von 'task'
existiert. Falls keine derartige Task existiert, wird 'niltask' geliefert.
name
- Code: 0x02 00 00 24
- Parameter: TASK task
- liefert: TEXT tasks name
- Wirkung: Die Task SUPERVISOR liefert einen Text mit dem externen
Tasknamen von 'task'. Falls 'task' nicht existiert, wird der Fehler
"'task' gibt es nicht" geliefert.
task
- Code: 0x02 00 00 25
- Parameter: TEXT taskname
- liefert: TASK task
- Wirkung: Die Task SUPERVISOR liefert den internen Taskbezeichner von
'taskname'. Falls es keine Task dieses Namens gibt, wird der
Fehler "'taskname' gibt es nicht" geliefert.
exists task
- Code: 0x02 00 00 26
- Parameter: TEXT taskname
- liefert: INT flag
- Wirkung: Die Task SUPERVISOR liefert '0', falls es eine Task 'taskname'
gibt, sonst '1'.
less than
- Code: 0x02 00 00 27
- Parameter: TEXT task1, task2
- liefert: INT flag
- Wirkung: Die Task SUPERVISOR liefert '0', falls die Task mit dem Namen
'task2' Vorfahre von 'task1' ist, sonst '1'.
Das Link Protokoll des Betriebssystems L3 umfaßt die Bedingungen und
Vorschriften für die Verbindung von Terminals und Tasks. Mit dem Begriff
»Terminal« ist im weiteren ein aus Tastatur und Bildschirm bestehender Arbeitsplatz
an einem L3 System gemeint. Es wird nicht zwischen der CONSOLE und
weiteren Arbeitsplätzen unterschieden.
Terminals werden in einem L3 System durch die Treibermanager (xy.kbd für
die Tastatur und xy.dsp für den Bildschirm) repräsentiert. Ein Treibermanager ist
die Schnittstelle zu einem Realprozeß. Der Realprozeß ist der »wirkliche« Hardwaretreiber. Die Manager für Tastatur und Bildschirm sind wiederum Sohntasks einer
Terminalmanagertask. Die Hierarchie für ein Terminal sieht also wie folgt aus:
TERMINAL 1 (* Terminalmanager *)
TERMINAL 1.term (* Terminalmenü (austauschbar) *)
TERMINAL 1.kbd (* virt. Treiber *)
SYSPRC TERMINAL 1.keyboard driver (* Realprozeß (Treiber) *)
TERMINAL 1.dsp
SYSPRC TERMINAL 1.display driver
Alle Terminals eines Systems sind Sohntasks von SYSIO, der Wurzel des Terminalzweiges innerhalb des Gesamtsystems.
Die Hierarchie aller Terminals eines Rechners stellt sich bei taskinfo wie folgt dar:
SYSIO
...
TERMINAL 1
TERMINAL 1.term
TERMINAL 1.kbd
TERMINAL 1.dsp
CONSOLE
CONSOLE.term
CONSOLE.kbd
CONSOLE.dsp
Ein Terminal in Gestalt seiner Treiberprozesse ist grundsätzlich mit irgendeiner Task
verbunden. Diese Task ist »Besitzer« des Terminals. Die Ausgaben des Besitzers
werden auf den Bildschirm geschrieben, Tastatureingaben an einem Terminal
werden dem Besitzer zugestellt. Der Ausgangszustand ist, daß Besitzer eines
Terminals der jeweilige Terminalmanager ist. Für die Koppelung eines Terminals an
eine Task gilt:
-
Der Anstoß zur Koppelung eines Terminals an eine Task kann nur vom Besitzer
kommen. Der Besitz wird also weitergereicht.
-
Wenn ein Besitzer das Terminal an eine andere Task weiterreicht, bleibt seine
Ankoppelung bestehen. Er kann jedoch nicht mehr mit den Treibern kommunizieren. Die Task wird in einen sogenannten Terminalstack geschrieben. Das hat
zur Folge, daß eine Task, die durch ein Paßwort geschützt ist, nur beim ersten
Ankoppeln die Eingabe des Paßwortes verlangt. Solange sie an das Terminal
gekoppelt bleibt, bzw. im Terminalstack steht, kann sie ohne erneute Paßworteingabe wieder aufgenommen werden.
-
Wenn ein Besitzer das Terminal abgibt, ohne es weiterzureichen, erhält der vorherige Terminalbesitzer das Terminal zurück. Die Task wird nicht in den
Terminalstack aufgenommen.
-
Wenn der <HotKey> (Tasten Strg Alt Del ) beim Besitzer betätigt wird,
wird der Terminalmanager neuer Besitzer.
-
Der Terminalmanager kann angekoppelte Prozesse anhalten. (HALT vom
Terminal).
-
Das Koppelungsmanagement wird von der Task SYSIO bewerkstelligt. Der Besitzer
eines Terminals muß SYSIO bitten, eine Task als neuen Besitzer anzukoppeln. Eine
Task, die ein Terminal benötigt, fragt bei SYSIO mit diesem Wunsch an.
Diese Organisation wird in der kontrollierenden Task SYSIO durch einen Terminalstack für jeden Terminalmanager erreicht. Die Task TERMINAL ist fest als unterste
Task in diesen Stack eingetragen. Sie gibt das Terminal an eine andere Task T weiter,
indem sie einen link request an SYSIO leitet. Dieser link request wird von SYSIO
an die gewünschte Task T geleitet. Falls diese ihr Einverständnis durch link exec
gibt, wird T an die Stackspitze gestellt und die Verbindung zwischen T und den
Treibern hergestellt. Damit ist der Besitzerwechsel vollzogen.
ACHTUNG:
Ein Besitzer, der das Terminal weitergeben will, muß den link request wiederholen,
bis die Weitergabe möglich ist, da nur so sichergestellt werden kann, daß er noch
Besitzer ist.
Eine Task, die ohne unbedingte Terminalausgaben (»im Hintergrund«) aktiv ist,
kann nur dann jemals wieder an ein Terminal gekoppelt werden, wenn sie irgendwann wieder bereit ist, eine Botschaft zu empfangen. Diese Botschaft, die gerade der
link request von SYSIO ist, muß von der Task zustimmend beantwortet werden
(link exec). Implizit wird diese Forderung dadurch erfüllt, daß die Task nach
Abschluß der Aktionen, die ohne Koppelung an ein Terminal durchgeführt wurden,
auf eine Eingabe wartet.
Die folgenden Meldungen sind diejenigen, die eine Task an SYSIO schicken kann, um
das Terminal weiter zu geben oder Informationen zu erhalten.
link request
- Code: 0x03 00 00 11
- Parameter: TASK next
- Wirkung: Der Besitzer des Terminals will das Terminal an 'next' weitergeben. Diese Botschaft an SYSIO muß wiederholt werden, solange
die sendende Task Besitzer des Terminals ist. Falls 'next' die von
SYSIO weitergeleitete Anfrage akzeptiert hat, wird vor Ausführen
der Koppelung zwischen Terminal und 'next' die Quittung link
ack von SYSIO gegeben. In jedem anderen Fall ist die Quittung
link nack.
link exec
- Code: 0x03 00 00 12
- Parameter: TASK terminal
TASK nexttask
- Wirkung: Mit dieser Meldung stimmt die Task 'nexttask' einer von SYSIO
zugestellten link request Anfrage zu. Falls die Task, die die
Weitergabe angestoßen hat, noch Eigentümer des Terminals ist,
wird 'nexttask' auf die Spitze des Terminalstacks gesetzt und
sowohl an die entsprechenden Terminaltreiber, als auch an
'nexttask' eine link order von SYSIO geschickt.
terminal request
- Code: 0x03 00 00 13
- Parameter: -
- Wirkung: Terminalanfrage an SYSIO. Wenn eine Task ein Terminal benötigt,
sendet sie diese Botschaft. Falls die Task bereits an ein Terminal
gekoppelt ist und an der Spitze des entsprechenden Taskstacks
steht, schickt SYSIO link order zurück. Falls ein link request
für die Task gestellt wurde, schickt SYSIO diesen weiter. In jedem
anderen Fall wird nicht geantwortet, die Task bleibt also im
geschlossenen Warten auf SYSIO.
terminal inquiry
- Code: 0x03 00 00 14
- Parameter: -
- Wirkung: Diese Botschaft kann eine Task an SYSIO senden, um zu erfragen,
ob sie an ein Terminal gekoppelt ist (link order ist bereits ausgeführt worden) oder die Zuweisung eines Terminals bevorsteht
(es gibt ein link request für die fragende Task). Falls die Task
am Terminal hängt, schickt SYSIO eine erneute link order an die
Task, falls ein link request für die fragende Task gestellt wurde,
antwortet SYSIO mit link request. In jedem anderen Fall
antwortet SYSIO mit link nack.
unlink
- Code: 0x03 00 00 15
- Parameter: TASK linked task
- Wirkung: Eine Task 'task an terminal' kann sich vom Terminal abkoppeln
und der Terminalprozeß kann eine Task, die in seinem Taskstack
bei SYSIO verzeichnet ist, durch diesen Auftrag vom Terminal
abkoppeln.
terminal
- Code: 0x03 00 00 22
- Parameter: TASK usertask
- liefert: TASK terminal
- Wirkung: Diese Anfrage an die Task SYSIO liefert den Terminalmanager, in
dessen Stack die Task 'usertask' verzeichnet ist.
'usertask' muß nicht online sein, d.h. 'usertask' muß nicht auf
der Spitze des Stacks für das betreffende Terminal stehen.
on line
- Code: 0x03 00 00 23
- Parameter: TASK usertask
- liefert: BOOL flag
- Wirkung: Diese Anfrage an die Task SYSIO liefert TRUE, falls 'usertask' an
der Spitze eines Terminalstacks steht.
Falls die Task nicht an ein Terminal gekoppelt ist, wird FALSE
geliefert.
Dabei ist es unerheblich, ob die Task in irgendeinem Terminalstack, aber dort nicht an der Spitze, oder überhaupt nicht in
einem solchen Stack ist.
link ack
- Code: 0x03 00 00 00
- Parameter: Weitere gelieferte Botschaftsabschnitte sind situationsabhängig.
- Wirkung: link acknowledge ist die Standardantwort auf irgendwelche Aufträge von Tasks, wenn diese Aufträge von SYSIO korrekt abgewickelt wurden.
link nack
- Code: 0x03 00 00 01
- Parameter: -
- Wirkung: link notacknowledge ist die Standardantwort auf irgendwelche
Aufträge von Tasks, wenn diese Aufträge von SYSIO nicht ausgeführt werden konnten.
Der Auftrag sollte dann wiederholt werden.
link order
- Code: 0x03 00 00 10
- Parameter:
- liefert: TASK terminal
- Wirkung: Diese Antwort erfolgt auf einen link exec Auftrag.
Zunächst erhalten Tastatur- und Bildschirmtreiber eine link
order für die Task. Anschließend erfolgt die link exec Botschaft
an die Task, die nun mit dem Treibern in Verbindung steht.
Dieses Protokoll beschreibt Botschaften von und an Tasks, die Dateimanager sind.
Eine Beschreibung der verschiedenen Typen von Managerprozeduren finden Sie in
Kapitel 8.
manager ack
- Code: 0x04 00 00 00
- Parameter: -
- Wirkung: Quittung einer Managertask, daß der Auftrag wunschgemäß und
ohne Fehler ausgeführt wurde. Dahinter folgen Rückgabe-
Parameter.
manager not ack
- Code: 0x04 00 00 01
- Parameter: -
- Wirkung: Falls eine Managertask einen Auftrag im Moment nicht ausführen
kann wird diese Antwort geschickt. Der Auftraggeber sollte den
Auftrag wiederholen.
manager error not ack
- Code: 0x04 00 00 03
- Parameter: TEXT errormsg, INT errorcode, errorline
- Wirkung: Bei der Bearbeitung des Auftrags ist ein Fehler passiert.
manager note ack
- Code: 0x04 00 00 04
- Parameter: TEXT message
- Wirkung: Antwort einer Managertask, die in Verbindung mit einer kurzen
textlichen Mitteilung an den Auftraggeber zurückgeschickt wird.
Beispielsweise wird die Mitteilung des Archivmanagers:
"Archiv nicht angemeldet"
mit diesem Antwortcode geschickt.
begin
- Code: 0x04 00 00 10
- Parameter: TEXT begin password
TEXT task name
INT begin privilege
INT begin start address
DATASPACE std ds
- liefert: TASK new task
- Wirkung: Falls das 'begin password' korrekt ist, erzeugt der Manager eine
neue Task nach folgendem Algorithmus:
IF begin start address >= 0
THEN begin (taskname,
(min (begin privilege, priv (myself)) ,
begin start address,
std ds,
new task)
ELSE begin (taskname,
(min (begiv priv, priv (myself),
address (PROC monitor),
next (nilspace),
new task)
FI
remove
- Code: 0x04 00 00 20
- Parameter: TEXT object name
- Wirkung: Das durch 'object name' bezeichnete Objekt wird gelöscht. Falls
das Objekt ein Verzeichnis ist, wird es nur gelöscht, wenn es leer
ist.
create
- Code: 0x04 00 00 21
- Parameter: TEXT object name
SHAPE object shape
- Wirkung: Ein Objekt namens 'object name' der Form 'object shape' wird
angelegt. Falls es bereits ein Objekt dieses Namens gibt, wird eine
Meldung ausgegeben: "'object name" existiert bereits'.
copy to
- Code: 0x04 00 00 22
- Parameter: TEXT dest name
DATASPACE source
ATTRIBUTES source attr
- Wirkung: Der Datenraum 'source' wird von der sendenden Task unter dem
Namen 'dest name in den Dateimanager kopiert. Unterverzeichnisse werden ggf. erzeugt.
copy from
- Code: 0x04 00 00 23
- Parameter: TEXT source name
- liefert: DATASPACE dest
ATTRIBUTES dest attr
- Wirkung: Der Datenraum 'source name' wird von der Managertask zum
Auftraggeber kopiert.
move from
- Code: 0x04 00 00 25
- Parameter: TEXT source name
- liefert: DATASPACE dest name
ATTRIBUTES dest attr
- Wirkung: Der Datenraum 'source name' wird von der Managertask zum
Auftraggeber geholt und im Manager gelöscht.
shape
- Code: 0x04 00 00 26
- Parameter: TEXT object name
- liefert: SHAPE object shape
- Wirkung: Liefert die Gestalt des Objekts 'object name'. Falls es kein Objekt
dieses Namens im Manager gibt wird nilshape geliefert.
attributes
- Code: 0x04 00 00 27
- Parameter: TEXT objekt name
- liefert: ATTRIBUTES object shape
is empty
- Code: 0x04 00 00 28
- Parameter: TEXT directory name
- liefert: BOOL dir is empty
- Wirkung: Liefert TRUE, falls das Verzeichnis existiert und keine Einträge
enthält. Falls das Verzeichnis existiert, aber nicht leer ist, wird
FALSE geliefert.
all
- Code: 0x04 00 00 29
- Parameter: TEXT directory name
SHAPE certain shape
- liefert: THESAURUS names
- Wirkung: Aus dem angegebenen Verzeichnis werden alle Objekte der
gewünschten Gestalt in der Namensliste 'names' geliefert.
list
- Code: 0x04 00 00 2A
- Parameter: TEXT directory name
SHAPE certain shape
- liefert: DATASPACE list space
- Wirkung: Aus dem angegebenen Verzeichnis werden alle Objekte der
gewünschten Gestalt in 'list space' gelistet. Der 'list space' ist ein
unbenannter Datenraum der inneren Struktur FILE, der zeilenweise Informationen über die gelisteten Objekte enthält (Datum
und Uhrzeit der letzten Änderung, Name).
xlist
- Code: 0x04 00 00 2B
- Parameter: TEXT directory name
SHAPE certain shape
- liefert: DATASPACE xlist space
- Wirkung: Aus dem angegebenen Verzeichnis werden alle Objekte der
gewünschten Gestalt in 'xlist space' gelistet. Der 'xlist space' ist ein
unbenannter Datenraum der inneren Struktur FILE. Es werden
auch alle Unterverzeichnisse des angegebenen Verzeichnisses mit
aufgelistet.
help
- Code: 0x04 00 00 2C
- Parameter:
- liefert: DATASPACE help space
- Wirkung: Der Manager liefert eine unbenannten Datenraum der inneren
Struktur FILE. Er enthält einen Hilfetext mit der Beschreibung der
Funktionen des Managers.
ds params
- Code: 0x04 00 00 2D
- Parameter: TEXT dataspace name
INT mode
- liefert: INT dataspace params
- Wirkung: 'mode'= 0 liefert die Größe des angegebenen Datenraums in
Byte, 'mode'= 2 liefert den Typ des Datenraums.
overwrite
- Code: 0x04 00 00 2e
- Parameter: TEXT source name
DATASPACE source
ATTRIBUTES source attributes
TEXT dest name
- Wirkung: Der Datenraum 'source' wird in den Manager kopiert. Falls dort
ein Datenraum dieses Namens existiert, wird der überschrieben.
copy to
- Code: 0x04 00 00 2f
- Parameter: TEXT source name
DATASPACE source
ATTRIBUTES source attributes
TEXT dest name
- Wirkung: Der Datenraum 'source' wird in den Manager kopiert. Falls dort
ein Datenraum dieses Namens existiert, liefert der Manager ein
manager not ack mit folgenden Parametern:DATASPACE
source, TEXT extended dest name, SHAPE dest shape
reserve
- Code: 0x04 00 00 30
- Parameter: TEXT reserve param
- Wirkung: Der Auftraggeber reserviert den Archivmanager. Alle Aktionen des
Archivmanagers werden ab Zeitpunkt der Reservierung exklusiv
vom Auftraggeber angestoßen.
release
- Code: 0x04 00 00 31
- Parameter: -
- Wirkung: Die Reservierung wird beendet.
volume name
- Code: 0x04 00 00 32
- Parameter:
- liefert: TEXT volume name
- Wirkung: Liefert den »volume name« des Archivmediums.
format
- Code: 0x04 00 00 33
- Parameter: INT format code
- Wirkung: Das Archivmedium wird für den erstmaligen Gebrauch vorbereitet,
also formatiert und initialisiert. Es wird physisch gelöscht.
Gültige Angaben für 'format code' bei Disketten sind:
0 High Density
360 DD 1S 360K
720 DD 2S 720K
1200 HD 5.25" 1200K
1440 HD 3.5" 1440K
clear
- Code: 0x04 00 00 34
- Parameter: -
- Wirkung: Das Archivmedium wird reinitialisiert, also logisch (aber nicht
physisch) gelöscht.
check
- Code: 0x04 00 00 35
- Parameter: TEXT object name
- Wirkung: Prüflesen.
volume storage
- Code: 0x04 00 00 36
- Parameter:
- liefert: INT size
INT used
- Wirkung: Liefert Größe und belegten Speicherplatz des Archivmediums in
Byte.
init medium
- Code: 0x04 00 00 38
- Parameter:
- liefert: INT medium type
- Wirkung: Initialisiert den Treiber des Archivmediums und liefert den Typ
des vorhandenen Archivmediums.
read
- Code: 0x04 00 00 39
- Parameter: BOOL cylinder orientated
INT sector no
INT stream length
- liefert: BYTESTRING stream
- Wirkung: Liest 'stream length' Bytes beginnend bei Sektornummer 'sector
no' von Archivmedium. 'stream length' muß ein Vielfaches der
Sektorgröße des Archivmediums sein.
write
- Code: 0x04 00 00 3A
- Parameter: BOOL cylinder orientated
INT sector no
BYTESTRING stream
- Wirkung: Schreibt 'stream length' Bytes beginnend bei Sektornummer
'sector no' auf das Archivmedium. 'stream length' muß ein Vielfaches der Sektorgröße des Archivmediums sein.
start
- Code: 0x04 00 00 40
- Parameter: TEXT password
- Wirkung: Der Spool wird aktiviert, indem eine neue Servertask (Taskname
'-') gestartet wird. Falls ein spool control password eingestellt
ist, muß dieses beigegeben werden. Falls der Spool bereits
aktiviert ist, erfolgt eine Fehlermeldung.
- Fehler: "Spool muß zuerst gestoppt werden"
stop
- Code: 0x04 00 00 41
- Parameter: TEXT password
TEXT deactivate message
- Wirkung: Der Spool wird deaktiviert, indem die Servertask gelöscht wird.
Falls eine Auftrag in Bearbeitung ist, wird die Bearbeitung
abgebrochen. Falls ein spool control password eingestellt ist,
muß dieses beigegeben werden. Falls eine Meldung 'deactivate
message' mitgegeben wird, wird diese Meldung bei list auf den
Spoolmanager ausgegeben.
halt
- Code: 0x04 00 00 42
- Parameter: TEXT password
TEXT deactivate message
- Wirkung: Der Spool wird deaktiviert, indem die Servertask nach Beendigung
des aktuellen Druckauftrags gelöscht wird. Falls ein spool
control password eingestellt ist, muß dieses beigegeben werden.
Falls eine Meldung 'deactivate message' mitgegeben wird, wird
diese Meldung bei list auf den Spoolmanager ausgegeben.
wait for halt
- Code: 0x04 00 00 43
- Parameter:
- Wirkung: Der Spool wird deaktiviert, indem die Servertask nach Beendigung
des aktuellen Druckauftrags gelöscht wird. Die Antwort wird
verzögert, bis der Spool deaktiviert ist. Falls ein spool control
password eingestellt ist, muß dieses beigegeben werden. Falls
eine Meldung 'deactivate message' mitgegeben wird, wird diese
Meldung bei list auf den Spoolmanager ausgegeben.
kill
- Code: 0x04 00 00 45
- Parameter: TEXT password
INT index
- Wirkung: Der indexte Eintrag in der Warteschlange des Spoolers wird
gelöscht. Falls ein spool control password eingestellt ist, muß
dieses beigegeben werden.
first
- Code: 0x04 00 00 46
- Parameter: TEXT password
INT index
- Wirkung: Der indexte Eintrag in der Warteschlange des Spoolers wird an die
erste Stelle gesetzt.Falls ein spool control password eingestellt
ist, muß dieses beigegeben werden.
log
- Code: 0x04 00 00 50
- Parameter: TEXT log message
- Wirkung: Der Text 'log message' wird in das »Logbuch« der Log Manager
Task eingetragen.
Next: Die Systemaufrufe
Up: L3 Referenzhandbuch
Previous: L3DOS
Michael Hohmuth
Sun Mar 31 04:49:53 MET DST 1996