#type ("trium8")##limit (11.0)# #start(2.5,1.5)##pagelength (17.4)# #block# #headeven# % EUMEL-Netzbeschreibung #end# #headodd# #center#Inhalt#right#% #end# #type ("triumb12")# 1. Einleitung Teil 1: Netz einrichten und benutzen #type ("trium8")# 1. Benutzung des Netzes 2. Hardwarevoraussetzungen 3. Einrichten des Netzes 4. Informationsmöglichkeiten 5. Eingriffsmöglichkeiten 6. Fehlerbehebung im Netz #type ("triumb12")# Teil 2: Arbeitsweise der Netzsoftware #type ("trium8")# 1. Die Netztask 2. Protokollebenen 3. Stand der Netzsoftware #page# #headodd# #center#Einleitung#right#% #end# #type("triumb12")# 1. Einleitung #type("trium8")# Das EUMEL-Netz dient dazu mehrere EUMEL-Rechner (sog. Stationen) mit­ einander zu koppeln. Diese Kopplung wird von Betriebsystem dazu benutzt, das Sendungskonzept (siehe Systemhandbuch 1.7, Intertaskkommunikation) so auszu­ dehnen, daß Tasks verschiedener Stationen einander Datenräume zusenden können. Auf dem Sendungskonzept aufbauende Konzepte nutzen daher automa­ tisch das Netz aus: So ist es z.B. möglich - von einer Station aus auf einer anderen zu Drucken, - in PUBLIC einer anderen Station Dateien zu sichern (save), vorausgesetzt, daß PUBLIC dort ein free global manager ist, - auf einer anderen Station zu archivieren (z.B. wenn das eigene Archivlaufwerk defekt ist oder ein anderes Format hat). Das Netz kann ab EUMEL-Version 1.7.3 eingesetzt werden. #type("triumb12")# Teil 1: Netz einrichten und benutzen 1. Benutzung des Netzes #type("trium8")# #headodd# #center#Teil 1: Netz einrichten und benutzen#right#% #end# Zur Benutzung des Netzes stehen folgende Operatoren und Prozeduren zur Verfügung: 1.1 TASK OP / (INT CONST station, TEXT CONST taskname) liefert die Task #on("bold")#taskname#off("bold")# von der Station #on("bold")#station#off("bold")#. Wenn die Station #on("bold")#station#off("bold")# nicht am Netz ist oder nicht eingeschaltet ist, wird solange gewartet, bis das der Fall ist. Fehlerfälle: - task "..." gibt es nicht Die angeforderte Task gibt es in der Zielstation nicht. - Collectortask fehlt Das Kommando #on("bold")#define collector#off("bold")# wurde nicht gegeben (siehe 4.2). - Station x antwortet nicht Eine nicht vorhandene oder abgeschaltete Station wurde angesprochen. Hinweis: Dieser Fehler wird angenommen, wenn eine Überwachungszeit von ca. 30 Sekunden verschrichen ist, ohne daß Station x die Taskidentifikation angeliefert hat. Beispiel: list (5/"PUBLIC") Dateiliste von PUBLIC auf Station 5 wird angefordert. 1.2 TASK OP / (INT CONST station, TASK CONST task) liefert station / name (task) . Beispiel: list (4/archive) 1.3 INT PROC station (TASK CONST task) liefert die Stationsnummer der Task #on("bold")#task#off("bold")#. Beispiel: put (station (myself)) gibt die eigene Stationsnummer aus. 1.4 PROC archive (TEXT CONST archivename, INT CONST station) dient dazu das Archiv auf der Station #on("bold")#station#off("bold")# anzumelden. Beispiel: archive ("std", 4); list (4/archive) gibt das Inhaltsverzeichnis der Archivfloppy im Laufwerk der Station 4 aus. Hinweis: Vergessen Sie bei solchen Querarchivierungen nicht die Stations­ angabe bei jedem einzelnen Archivkommando (z.B fetch ("xxx", #on("bold")#4/#off("bold")# archive). Hinweis: Querarchivieren ist langsam. Verwenden Sie es nur, wenn Sie Flop­ pyformate umsetzen wollen. 1.5 PROC free global manager dient dazu, die eigene Task über das Netz ansprechbar zu machen. Jede andere Task im Netz kann dann die üblichen Manageraufrufe ('save', 'fetch', u.s.w.) an die eigene Task machen, sofern diese nicht an ein Terminal gekop­ pelt ist. Die Task wird (wie bei 'break') abgekoppelt und meldet sich in Zukunft mit 'maintenance' statt mit 'gib kommando'. Beispiel: An Station 4 ruft man in der Task 'hugo' das Kommando #on("bold")#free global manager#off("bold")# auf. Anschließend kann man von jeder Station aus z.B. 'list (4/"hugo")' u.s.w. machen. 1.6 TEXT PROC name (TASK CONST t) Diese (schon immer vorhandene) Prozedur wurde dahingehend erweitert, daß der Name einer Task einer anderen Station über Netz angefordert wird. Fehlerfall: Station x antwortet nicht #type("triumb12")#2. Hardwarevoraussetzungen#type("trium8")# 2.1 Zwei Stationen Sie können zwei Stationen miteinander Vernetzen, wenn Sie dafür an jeder Station eine V24-Schnittstelle zur Verfügung stellen. Diese beiden Schnittstellen verbinden Sie mit einem Kabel zur Rechner­ kopplung (siehe Systemhandbuch 1.7 Teil 2). 2.2 Mehrere Stationen Wenn Sie mehr als zwei Stationen vernetzen wollen, brauchen neben je einer V24 an jeder Station noch je eine Netzanschlußbox. Jede Box besitzt eine V24-Schnittstelle zum Anschluß an die V24- Schnittstelle der zugeorneten Station und eine weitere Schnittstelle zur Verbindung der Boxen untereinander. #type("triumb12")#3. Einrichten des Netzes #type("trium8")# Hinweis: Dieses Kapitel ist nur für Systembetreuer wichtig. 3.1 Legen Sie Stationsnummern für die am Netz beteiligten Rechner fest (von 1 an aufsteigend). Die Boxen haben ebenfalls Stationsnummern. Die Stationsnummern der Box und des zugeordneten Rechners müssen übereinstimmen. 3.2 Holen Sie an jeder Station die Task #on("bold")#configurator#off("bold")# an ein Terminal und geben Sie das Kommando #on("bold")#define collector ("net port")#off("bold")#. Geben Sie außerdem das Kommando #on("bold")#define station (x)#off("bold")#, wobei #on("bold")#x#off("bold")# die gewählte Stationsnummer ist. Hinweis: Taskkommunikationen, die zu dem Zeitpunkt laufen, führen zu feh­ lerhaften Verhalten. Dies liegt daran, daß durch #on("bold")#define station#off("bold")# alle Task-Id's geändert werden müssen, weil eine Task-Id u.a. die Stationsnummer der eigenen Station enthält (siehe 2.3). TASK- Variable, die noch Task-Id's mit keiner oder falscher Stationsnum­ mer enthalten, können nicht mehr zum Ansprechen einer Task verwendet werden. Beispiel: Der Spoolmanager (siehe Benutzerhandbuch 1.7 Teil 12) richtet beim Kommando #on("bold")#start#off("bold")# einen Worker ein und merkt sich dessen Task-Id in einer TASK-Variablen, um sicherzustellen, daß nur der Worker Dateien zum Drucken abholt. Wird jetzt das Kommando #on("bold")# define station#off("bold")# gegeben, kann der Spoolmanager seinen Worker nicht mehr identifizieren, weil der Worker eine neue Task-Id er­ halten hat. Man muß daher den Worker löschen und mit dem Kommando #on("bold")#start#off("bold")# im Spoolmanager wieder neu einrichten. Sinnvollerweise gibt man #on("bold")#define station#off("bold")# sofort nach den Laden eines frischen Systems von Archiv. Konfigurieren Sie mit dem Kommando #on("bold")#configurate#off("bold")# den für das Netz vorgese­ henen Kanal auf - transparent - 9600 Baud (Standardeinstellung der Boxen) - RTS/CTS-Protokoll - großen Puffer - 8 bit - even parity - 1 stopbit. Falls diese Einstellungen nicht alle angeboten werden, klären Sie mit Ihrem Rechnerlieferanten, ob und wie diese Einstellungen erreicht werden können. Hinweis: Notfalls kann auf das RTS/CTS-Protokoll verzichtet werden, wenn der Eingabepuffer der Station groß genug ist. Die Anzahl simultan laufender Netzkommunikationen ist dann auf puffergröße DIV 150 begrenzt (bei Z80, 8086: 3; bei M20: 10). Hinweis: Es können auch andere Baudraten (2400, 4800, 19200) an der Box eingestellt werden. 3.3 Achten Sie bei der Verbindung von der Station zur Netzbox (bzw. zur Gegen­ station bei einem Zweistationennetz ohne Boxen) darauf, daß neben den Empfangs- und Sendeleitungen auch die Leitungen RTS und CTS verdrahtet werden, also ein 5 poliges Kabel verwendet wird (siehe Systemhandbuch 1.7 Teil 2). Die Pin-Belegung der Boxen entspricht den dortigen Angaben. Beispiel: Verbindung eines CSK-Systems mit der Box: Stecker Stecker Pin Pin 2 <---------> 3 3 <---------> 2 4 <---------> 5 5 <---------> 4 7 <---------> 7 3.4 Richten Sie eine Task #on("bold")#net#off("bold")# unter #on("bold")#SYSUR#off("bold")# ein und insertieren Sie dort die Datei­ en net report/M basic net net manager/M. Beantworten Sie die Frage nach dem Kanal für das Netz und nach der Fluß­ kontrolle (RTS/CTS). #type("triumb12")#4. Informationsmöglichkeiten #type("trium8")# In der Task #on("bold")#net#off("bold")# wird eine Datei #on("bold")#report#off("bold")# geführt in der Fehlersituationen des Netzes verzeichnet werden. Diese Datei kann in jeder anderen Task mit #on("bold")#list (/"net")#off("bold")# angezeigt werden. In jeder Task kann durch das Kommando #on("bold")#list (/"net port")#off("bold")# eine Übersicht über die momentan laufenden Netzübertragungen der eigenen Station erhalten werden. #type("triumb12")#5. Eingriffsmöglichkeiten #type("trium8")# #headodd# #center#Eingriffsmöglichkeiten#right#% #end# 5.1 Jede Task kann Sende- und Empfangsströme, die bei #on("bold")#list (/"net port")#off("bold")# gemel­ det worden sind und die eigene Task betreffen, abbrechen. Hierzu ist das Kommando #on("bold")#erase ("x",/"net port")#off ("bold")# zu geben, wobei x die Stromnummer (aus dem 'list') ist. Unberechtigte Löschversuche werden abgewiesen. Von der Task 'net' aus können jedoch damit beliebige Ströme abgebrochen werden. 5.2 Durch das Kommando #on("bold")#start#off("bold")# kann von der Task 'net' aus das Netz neu gestartet werden. Dabei werden alle augenblicklichen Netzkommunikationen gelöscht. Die Tasks 'net port' und 'net timer' werden dabei gelöscht und neu eingerich­ tet. #on("bold")#start (kanal, quit)#off("bold")# wirkt wie #on("bold")#start#off("bold")#. Zustzlich wird als Netzkanal 'kanal' eingestellt und maximal 'quit' Empfangsströme zugelassen. 'quit' ist auf 3 zu setzen, wenn der Kanal ohne RTS/CTS angeschlossen ist (siehe 3.2). #type("triumb12")#6. Fehlersuche im Netz #type("trium8")# Fehler im Netz können sich verschiedenartig auswirken. Im Folgenden wird auf einige Beispiele eingegangen: Beispiel: Auf #on("bold")#list (4/public)#off("bold")# erfolgt die Meldung 'Station 4 antwortet nicht'. Fehlermöglichkeiten: - Station 4 gibt es nicht am Netz. Abhilfe: Richtige Station angeben. - Station 4 ist nicht eingeschaltet. Abhilfe: Station 4 einschalten. Kommando erneut geben. - Netztask an Station 4 ist nicht arbeitsfähig. Abhilfe: Kommando 'start' in der Task 'net'. - Stationsnummern und Boxnummern stimmen nicht überein. Abhilfe: Mit 'define station' Stationsnummern korrigieren (siehe 3.2). - Verbindung Rechner/Box am eigenen Rechner oder an Station 4 fehlt. Abhilfe: Verbindungen überprüfen. Durch Ansprechen einer dritten Station kann oft schnell geklärt werden, welche Rechner/Box-Verbindung defekt sein muß. - Verbindung der Boxen untereinander defekt. Abhilfe: Fehlende Verbindung, Masseschluß und Dreher (keine 1:1 Ver­ bindung) überprüfen und beheben. Hinweis: Liegt z.B. ein Masseschluß vor, so kann es durchaus sein, daß Boxen, die nicht in der Nähe des Masseschluß stehen noch mitei­ nander arbeiten können. Man kann aus der Tatsache, daß zwei Boxen miteinander arbeiten können, also nicht schließen, daß man nicht nach diesem Fehler suchen muß. Beispiel: Auf #on("bold")#list (4/public)#off("bold")# erfolgt keine Reaktion. - Station 4 ist während dieser Sendung zusammengebrochen. Abhilfe: Station 4 wieder starten. Die Bearbeitung des 'list'-Kommandos wird automatisch wieder aufgenommen. - PUBLIC auf Station 4 ist nicht im Managerzustand. Abhilfe: PUBLIC in den Managerzustand versetzen. Hinweis: Das Netz hat nocht nicht die volle Sendungslogik des EUMEL. So wird nur ca. 10 Minuten lang versucht, eine Sendung zuzustellen. Danach wird die Sendung gelöscht. Ist dies eingetreten, so muß das list-Kommando erneut gegeben werden. - Fehler in der Netzhardware. Überprüfen Sie, ob - die Boxen eingeschaltet sind, - die Bereitlampe blinkt (wenn nicht: RESET an der Box) - die V24-Kabel richtig stecken, - die Boxen untereinander verbunden sind (1 zu 1 Verbindungen der 5 poligen Diodenbuchsen). - Die Netzsoftware ist auf einen nicht vorhergesehenen Fehler gelaufen. Dieser wird im Report vermerkt. Abhilfe: Geben Sie in der Task #on("bold")#net#off("bold")# das Kommando #on("bold")#start#off("bold")#. Dadurch wird die Netzsoftware neu gestartet. Alle Netzkommunikationen dieser Station gehen verloren. Beispiel: Auf #on("bold")#list (4/public)#off("bold")# erfolgt die Meldung 'Collectortask fehlt'. - In der Task 'configurator' wurde das Kommando 'define collector' (siehe 3.2) nicht gegeben. - Die Task 'net port' existiert nicht mehr. Abhilfe: Kommando 'start' in der Task 'net'. Beispiel: Nach #on("bold")#fetch ("hugo",4/public)#off("bold")# sind Teile von der Datei "hugo" verfälscht. - Die V24-Verbindung zur Box ist nicht in Ordnung. Abhilfe: Abstand zwischen Rechner und Box verkürzen; Baudrate ernie­ drigen; Durch Wechseln der V24-Schnittstelle feststellen, ob diese defekt ist. Hinweis: Die Verbindung zwischen den Boxen ist durch Prüfsummen abge­ sichert (Hardware). #headodd# #center#Teil 2: Arbeitsweise der Netzsoftware#right#% #end# #page# #type("triumb12")# Teil 2: Arbeitsweise der Netzsoftware 1. Die Netztask #type ("trium8")# In diesem Kapitel wird beschrieben, wie eine Netztask in das System eingebettet ist und welche Aufgaben sie hat. Unter Einhaltung dieser Konzepte kann die ausgelieferte Netztask so geändert werden, daß sie beliebige andere Netzhardware unterstützt. Z.Zt. ist die Netzsoftware noch nicht so gegliedert, daß nur eine hardwareabhängige Komponente ausgetauscht werden muß. Die Kommunikation zwischen Tasks im EUMEL-Betriebssystem basiert auf einem Rendevouskonzept: Die Zieltask einer Sendung muß empfangsbereit sein, wenn die Quelltask sendet. Die Kommunikationsprozeduren auf der niedrigsten Ebene sind 'send' (Senden) und 'wait' (Warten auf Empfang). Bei der Kommunikation werden eine Integer 'code' und ein Datenraum 'dr' übergeben. 'code' muß >= 0 sein, da negative Codes systemintern verwandt werden. Ist die empfangende Task an einen Kanal gekoppelt ('continue'), so führt eine Zeicheneingabe auf diesem Kanal dazu, daß eine Sendung mit dem Code -4 ankommt. Die Eingabedaten müssen mit den üblichen Eingabeprozeduren ('inchar' u.s.w.) abgeholt werden. Der übermittelte Datenraum und die Absendertask sind dabei ohne Bedeutung und dürfen nicht interpretiert werden. Die Prozedur 'send' hat einen Rückmeldeparameter, der besagt, ob die Sendung übermittelt wurde. Gibt es die Zieltask nicht oder steht sie nicht im 'wait', so kann die Sendung nicht übermittelt werden. Ein Entwicklungskriterium für das EUMEL-Netz war es, möglichst wenig Unter­ stützung von der virtuellen EUMEL-Maschine (EUMEL0) zu fordern, damit weit­ gehend in ELAN programmiert werden kann. Dadurch ist es möglich eine (privili­ gierte) Task mit der Netzabwicklung zu betrauen. Zunächst wird auf die EUMEL0-Unterstützung eingegangen: 1.1. Es gibt die Prozedur 'define collector', mit der die für das Netz verantwort­ liche Task der EUMEL0-Maschine bekannt gemacht wird. Diese Task wird im folgenden Collector genannt. 1.2. Es gibt die Prozedur 'define station', die für den Rechner eine Stationsnum­ mer einstellt. Anhand dieser Nummer werden die Rechner eines Netzes un­ terschieden. Das Einstellen bewirkt, daß für alle Tasks die Stationsnummer in ihre Task-Id eingetragen wird (Task-Id's sind die Werte, die der Typ TASK annehmen kann). 1.3. Der Befehl 'station (task)' liefert die Stationsnummer der 'task'. So liefert z.B. 'station (myself)' die Stationsnummer des eigenen Rechners. 1.4. Eine Sendung, deren Zieltask in einem anderen Rechner liegt (also station (ziel) <> station (myself)), wird auf die Collectortask geleitet. 1.5. Es gibt eine Prozedur 'collected destination', die es dem Collector erlaubt, die eigentliche Zieltask einer auf ihn geleiteten Sendung zu erfahren. 1.6. Es gibt eine Variante der Prozedur 'send', die es dem Collector gestattet, der Zieltask eine beliebige andere Task als Absender vorzumachen. 1.7. Es gibt eine spezielle Task-Id 'collector', durch die der augenblicklich ein­ gestellte Collector erreicht wird. Diese wird als Zieltask beim Aufruf der Ver­ mittlungsdienste angegeben (siehe 2.5). Eine Sendung an 'collector' wird von EUMEL0 an den derzeitigen Collector geschickt. Ein Collector kann also auf drei Wegen von den übrigen Tasks desselben Rechners Sendungen erhalten: 1. Über ein normales Send (z.B. bei 'list (/"net port")', wenn "net port" der der­ zeitige Collector ist), 2. über ein Send an die Task 'collector' (s.u.) und 3. als umgeleitete Sendung (z.B. bei 'list' an eine Task auf einem anderen Rechner). Der Collector kann diese Fälle anhand von 'collected destination' unterscheiden. Die Punkte 1.4...1.6 dienen dazu, den Collector für über Netz kommunizierende Task unsichtbar zu machen: Der Collector taucht nicht als Ziel oder Quelle von Sendungen auf. Das ist notwendig, damit normale Tasks sich nicht darum kümmern müssen, ob eine Sendung übers Netz geht oder im eigenen Rechner bleibt. Wenn ein Datenraum an einen anderen Rechner geschickt wird, muß der gesamte Inhalt (z. Zt. max. 1 MB) übertragen werden. Dies macht bei der üblichen Netz­ hardware eine Zerlegung in Packete nötig (siehe Systemhandbuch 173, Teil 4, Punkt 5). Für Netze über V24-Kanäle stehen spezielle Blockbefehle zur verfü­ gung: 1.8. blockin / blockout (dr,seite,512+abstand,anzahl,rest) Es werden maximal 'anzahl' Bytes transferiert. In 'rest' wird zurückgemeldet, wieviel Bytes nicht bearbeitet wurden (z.B. weil der Kanal nichts anliefert). Bearbeitet werden die Bytes 'seite' * 512 + 'abstand' bis maximal 'seite' * 512 + 'abstand' + 'anzahl' - 1 Der Kanal, an den die Task gekoppelt ist, wird dabei über Stream-IO (d.h. 'incharety' bei 'blockin' bzw. 'out' bei 'blockout') angesprochen. Hinweis: Die Anforderung darf nicht über Seitengrenze gehen, d.h. 'abstand' + 'anzahl' <= 512 muß erfüllt sein. Eine Netzsendung läuft wie folgt ab: Die Task q auf Rechner rq mache ein 'send' an die Task z auf Rechner rz. 1. Die Prozedur send ist ein EUMEL0-Befehl. Die EUMEL0-Ebene erkennt, daß die Sendung an die Station rz geht, da die Stationsnummer in der Task-Id enthalten ist. Daher wird die Sendung zum Collector, den EUMEL0 wegen 'de­ fine collector' kennt, umgeleitet. 2. Die Task Collector empfängt über 'wait' den Datenraum, den Sendecode und die Absendertask q. Die Zieltask z erfährt sie durch 'collected destination'. 3. Der Collector nimmt Kontakt mit dem Collector des Rechner rz, dessen Sta­ tionsnummer ja 'station(z)' ist, auf und Übermittelt diesem Sendecode, Quelltask (q), eigentliche Zieltask (z) und den Datenraum. Da die Collectoren in ELAN geschrieben sind, können sie an beliebige Netzhardware und Protokolle ange­ paßt werden. 4. Der Collector auf Rechner rz verwendet das spezielle 'send', um der Zieltask die Sendung zuzustellen. Dadurch erscheint nicht der Collector sondern die Task q als Absender der Sendung. Zur Abwicklung der Vermittlungsebene (Teil 1: 2.4) muß der Collector noch spezielle Funktionen beherrschen. Diese sind der /-Operator (Taskname in Task-Id wandeln) und die name-Prozedur (Task-Id in Namen wandeln). Der /-Operator macht eine Sendung an den 'collector', wobei im Datenraum der Name der Task steht und der Sendecode gleich der Stationsnummer ist (siehe Quellcode 173, Packet tasks). Der Collector setzt sich mit dem Collector dieser Sta­ tion in Verbindung, damit dieser die Task-Id ermittelt und zurückschickt. Der eigene Collector schickt dann dem /-Operator als Antwort einen Datenraum, der die Task-Id enthält. Umgekehrt läuft 'name' ab: Wenn die Task-Id von einer fremden Station ist, schickt 'name' eine Sendung an den 'collector', wobei im Datenraum die Task-Id steht und Sendecode = 256 ist. Der Collector entnimmt die Stationnummer der Task aus der Task-Id und läßt sich vom entsprechenden Collector den Tasknamen geben. Dieser wird der 'name'-Prozedur im Antwortdatenraum übergeben. #type ("triumb12")#2. Ebenen #type("trium8")# In diesem Kapitel werden die Protokollebenen für das Netz beschrieben, wie sie die ausgelieferte Netzsoftware benutzt und erwartet. Bei anderer Netzhardware müssen die Ebenen 1 bis 3 ausgetauscht werden. Unter Einhaltung der im vorigen Kapitel beschriebenen Randbedingungen können auch die höheren Ebenen geändert werden. 2.1 Physikalische Ebene 2.1.1 Station <--> Box V24-Schnittstelle mit RTS/CTS-Handshake. Vollduplex. 2.1.2 Box <--> Box RS422 über 2 verdrillte Leitungspaare (Takt und Daten). 2.2 Verbindungsebene 2.2.1 Station <--> Box Asynchron 8 Bit Even Parity 2400/4800/9600/19200 Baud (einstellbar über Lötbrücken) 2.2.2 Box <--> Box SDLC 400 KBaud 2.3 Netzebene 2.3.1 Station <--> Box Telegrammformat: STX, , , , <(n-4) byte> ist Längenangabe ( 8 <= n <= 160) , sind Stationsnummern. Diese müssen an den je­ weiligen Boxen über Lötbrücken eingestellt sein. Box --> Station: Ein Telegramm kommt nur bei der Station an, bei deren Box die Nummer eingestellt ist. Dadurch ist ein Mithören fremder Übertragungen nicht möglich (Datenschutz). Zwischen Telegrammen können Fehlermeldungen der Box (Klartext) übermittelt werden (z.B. 'skipped x', wenn ein STX von der Box er­ wartet wurde, aber 'x' von der Station ankommt). Station --> Box: Ein Telegramm wird nur abgeschickt, wenn mit der einge­ stellten Nummer übereinstimmt (Datenschutz: Man kann nicht eine beliebige Station zu sein vorschwindeln, es sei denn man hat physi­ schen Zugriff zur Box und stellt dort die Stationsnummer um). 2.3.2 Box <--> Box Telegrammformat: FRAME, , , , Eine Längenangabe ist nicht nötig, da SDLC eine Rekonstruktion der Länge erlaubt. Telegramme mit falschen CRC-Code werden vernichtet. Auf höheren Ebenen muß dies durch Zeitüberwachung erkannt und behandelt werden. 2.4 Transportebene Diese Ebene wickelt das Rendevous zwischen einer Task, die 'send' macht, und einer Task, die im 'wait' steht, ab (siehe: EUMEL-Systemhandbuch). Der im 'send' angegebene Datenraum wird als Folge von Seiten (im EUMEL-Sinne: Pagingeinheit und Allokiereinheit) übermittelt, wobei jede Seite noch in 64 Byte große Stücke zerlegt wird. Es werden nur echt allokierte Seiten übermittelt. Um nicht jedes Telegramm voll qualifizieren zu müssen, wird zunächst eine Art virtuelle Verbindung durch ein OPEN-Telegramm eröffnet. Danach folgen variable viele DATA-Telegramme. Beide Sorten werden durch QUIT-Telegramme quittiert, um folgende Funktionen zu ermöglichen: Flußkontrolle (z.B. Zielrechner langsam) Wiederaufsetzen (verlorene Telegramme) Abbruch (z.B. weil Zieltask inzwischen beendet). Ein CLOSE-Telegramm ist nicht nötig, da das letzte DATA-Telegramm als solches erkannt werden kann (siehe unten). 2.4.1 OPEN-Telegramm STX, 20, , , , , , , , , siehe 2.3.1 Die Stromnummer identifiziert die virtuelle Verbindung. Sie muß in den QUIT-Telegrammen angegeben wer­ den. -1 (Kennzeichen für OPEN) Nummer der ersten echt allokierten Seite des Datenra­ ums (=-1, falls Nilspace) Taskid der sendenden Task Taskid der empfangenden Task Wert des im 'send' angegebenen Codes. 2.4.2 DATA-Telegramm STX, 74, , , , , <64 byte> wird von Telegramm zu Telegramm hochgezählt. Dient der Überwachung gegen verlorengegangene Telegramme bzw. durch Zeitüberwachung verdoppelter Telegramme. Nummer der x.ten echt allokierten Seite des Datenra­ ums. (x = (+16) DIV 8). <64 byte> Nutzinformation. Diese gehört zur Adresse a des Daten­ raums. a = N ( DIV 8 + 1) * 512 + ( MOD 8) * 64 wobei N (x) die Nummer der x.ten Seite ist. Aus den Formeln ergibt sich, daß diese Nummer schon in einem vorhergehenden DATA/OPEN-Telegramm über­ mittelt wurde (im Feld ). 2.4.3 QUIT-Telegramm STX, 8, , , , muß die Stromnummer sein, die in dem OPEN/DATA- Telegramm stand, das quittiert wird. 0 : ok. Nächstes Telegramm schicken. -1: Übertragung neu starten (mit OPEN), weil die Empfangsstation das OPEN nicht erhalten hat. -2: Übertragung ca. 20 Telegramme zurücksetzen. -3: Übertragung abbrechen. 2.5 Vermittlungsebene Diese Ebene ist dafür zuständig, Tasknamen von Task auf anderen Stationen in Taskids (Werte des Typs TASK) zu wandeln und umgekehrt. Hierzu wird im entsprechenden OPEN-Telegramm der Code -6 (bzw. -7) als eingetragen. Die Netzempfangstask erkennt diese Codes und wickelt die Aufgaben selbst ab, sodaß es dabei nicht nötig ist, irgendeine Taskid der Zielstation zu kennen. Dieses Verfahren ist möglich, weil im 'send' nur positive Codes erlaubt sind. 2.6 Höhere Ebenen Höhere Ebenen sind nicht mehr netzspezifisch. Sie basieren alle auf dem Send/Wait-Konzept des EUMEL. So gibt es z.B. den 'global manager', der Aufbewahrung und Zugriff von Dateien in einer Task regelt. Dabei darf diese Task (bei der Variante 'free global manager') auf einer beliebigen Station im Netz liegen. Wegen des Rendevous-Konzepts können beliebige Sicherheit­ strategien benutzt werden (z.B.: Keine Dateien an Station 11 ausliefern). Von großen Wert ist z.B., daß man ohne weiteres das Archiv (Floppylaufwerk) einen anderen Station anmelden und benuzten kann, wodurch eine einfache Kon­ vertierung von Floppyformaten möglich ist. Dies ist möglich, weil auch die Ar­ chiv-Task der Stationen sich an das Globalmanagerprotokoll halten. #type("triumb12")# Bemerkungen#type("trium8")# Fehlerbehandlung besteht bis Ebene 3 darin, fehlerhafte Telegramme einfach zu entfernen. Die Ebene 4 überwacht den Netzverkehr sowieso über Timeouts, die eine Wiederhohlung eines Telegrammes bewirken, wenn die Quittung ausbleibt. Da bei der sendenden Station der ganze Datenraum zur Verfügung steht, ist eine Fenstertechnik (wie bei HDLC) nicht nötig. Es kann zu jedem Zeitpunkt um beliebig viele Telegramme zurückgesetzt werden. Da im EUMEL eine Textdatei ein Datenraum mit sehr komplexer Struktur ist (wegen der Insert/Delete-Möglichkeiten, ohne den Rest der Datei zu schieben), ist es ein hoher Aufwand, von einem fremden Betriebssytem her Textdateien ins EUMEL- Netz zu senden. Für solche Zwecke muß noch eine einfachere Dateistruktur defi­ niert werden und entsprechende Dateikonverter erstellt werden. #type("triumb12")#3. Stand der Netzsoftware #type("trium8")# Das EUMEL-System wickelt die Prozedur #on("bold")#send#off("bold")# über das Netz ab, wenn die Stationsnummer der Zieltask ungleich der eigenen Stationsnummer ist. Umge­ kehrt kann man der von der Prozedur #on("bold")#wait#off("bold")# gelieferten Absendertask die Absen­ derstation entnehmen (siehe Prozedur #on("bold")#station#off("bold")# in Abschnitt 3). Nicht unterstützt wird z.Zt. die Logik der Prozeduren #on("bold")#call#off("bold")# und #on("bold")#pingpong#off("bold")#. Diese funktionieren nur in der gewohnten Weise, wenn die Zieltask in #on("bold")#wait#off("bold")# steht. Ist die Zieltask länger als ca. 10 Minuten #on("bold")#busy#off("bold")# oder nicht mehr vorhanden, geht die Sendung einfach verloren (Gefordert ist: bei #on("bold")#call#off("bold")#: immer wieder versuchen; bei #on("bold")# pingpong#off("bold")#: Rückmeldung -2). Wegen dieser Einschränkung kann man z.B. ein sicheres Drucken von Station a auf einen Drucker der Station b nur durch einen eigenen Spoolmanager auf Station a verwirklichen. Die Einrichtung eines solchen Managers ist allerdings sowieso sinnvoll, damit man - das normale 'print'-Kommando verwenden kann (statt z.B. save ("xxx", 4/printer);) und - nicht zu warten braucht, bis die Datei übers Netz gesendet ist.