path: root/system/net/1.7.5/doc/EUMEL Netz

#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>, <ziel>, <quelle>, <(n-4) byte> 
 
           <n> ist L�ngenangabe ( 8 <= n <= 160) 
           <ziel>, <quelle> 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 <ziel> 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 <quelle> 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, <ziel>, <quelle>, <daten> ,
           <CRC-Code> 
 
           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, <ziel>, <quelle>, <strom>, <sequenz>, <seite>, 
          <quelltask>, <zieltask>, <code> 
 
          <ziel>, <quelle> siehe 2.3.1 
 
          <strom>      Die Stromnummer identifiziert die virtuelle Verbindung.
                       Sie mu� in den QUIT-Telegrammen angegeben wer-
                       den. 
 
          <sequenz>    -1 (Kennzeichen f�r OPEN) 
 
          <seite>      Nummer der ersten echt allokierten Seite des Datenra-
                       ums (=-1, falls Nilspace) 
 
          <quelltask>  Taskid der sendenden Task 
 
          <zieltask>   Taskid der empfangenden Task 
 
          <code>       Wert des im 'send' angegebenen Codes. 
 
    2.4.2 DATA-Telegramm 
 
          STX, 74, <ziel>, <quelle>, <sequenz>, <seite>, <64 byte> 
 
          <sequenz>    wird von Telegramm zu Telegramm hochgez�hlt. Dient
                       der �berwachung gegen verlorengegangene Telegramme
                       bzw. durch Zeit�berwachung verdoppelter Telegramme. 
 
          <seite>      Nummer der x.ten echt allokierten Seite des Datenra-
                       ums. (x = (<sequenz>+16) DIV 8). 
 
          <64 byte>    Nutzinformation. Diese geh�rt zur Adresse a des Daten-
                       raums. 
 
                       a = N (<sequenz> DIV 8 + 1) * 512 
                           + (<sequenz> 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 <seite>). 
 
    2.4.3 QUIT-Telegramm 
 
          STX, 8, <ziel>, <quelle>, <strom>, <quit> 
 
          <strom>      mu� die Stromnummer sein, die in dem OPEN/DATA-
                       Telegramm stand, das quittiert wird. 
 
          <quit>       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 <code>
    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.