4 Das OLGA-Protokoll...

• 4.1 ...als Minimalversion
• 4.1.1 Server
• 4.1.2 Client
• 4.2 ...für Server und Client
• 4.2.1 Nachstarten des OLGA-Managers
• 4.2.2 OLE_INIT
• 4.2.3 OLGA_INIT
• 4.2.4 OLE_EXIT
• 4.2.5 OLE_NEW
• 4.3 ...aus der Sicht des Servers
• 4.3.1 OLGA_UPDATE
• 4.3.2 OLGA_GETINFO
• 4.3.3 OLGA_INFO
• 4.3.4 OLGA_RENAME
• 4.3.5 OLGA_BREAKLINK
• 4.3.6 OLGA_CLIENTTERMINATED
• 4.4 ...aus der Sicht des Clients
• 4.4.1 OLGA_OPENDOC
• 4.4.2 OLGA_CLOSEDOC
• 4.4.3 OLGA_LINK
• 4.4.4 OLGA_UNLINK
• 4.4.5 OLGA_UPDATED
• 4.4.6 OLGA_RENAMELINK
• 4.4.7 OLGA_LINKRENAMED
• 4.4.8 OLGA_LINKBROKEN
• 4.4.9 OLGA_START
• 4.4.10 OLGA_SERVERTERMINATED

4.1 ...als Minimalversion

Im folgenden sind die Messages aufgelistet, die Server bzw. Client minimal unterstützen müssen, um eine korrekte Protokollbehandlung zu gewährleisten.

• 4.1.1 Server
• 4.1.2 Client

4.1.1 Server

• OLE_INIT verschicken
   
• OLE_NEW auswerten
   
• OLGA_INIT empfangen
   
• OLE_EXIT verschicken
   
• VA_START unterstützen (s. Gemini-Doku, AV-Protokoll)
   

Damit der Server auch wirklich als solcher fungiert, muß natürlich noch die Message OLGA_UPDATE verschickt werden.

4.1.2 Client

• OLE_INIT verschicken
   
• OLE_NEW auswerten
   
• OLGA_INIT empfangen
   
• OLE_EXIT verschicken
   
• auf OLGA_RENAMELINK mit OLGA_LINKRENAMED antworten
   
• auf OLGA_LINKBROKEN mit OLGA_UNLINK antworten
   

Ein Client sollte sinnvollerweise auch auf OLGA_UPDATED reagieren.

4.2 ...für Server und Client

Das OLGA-Protokoll besteht im wesentlichen aus dem Kommunikation mit dem OLGA-Manager. Dazu muß man die AES-ID des Managers kennen, die wie folgt ermittelt wird:

1. Wenn appl_find("OLGA    ") erfolgreich ist, hat man den Manager schon gefunden.
    
2. Ansonsten wird nun die Environmentvariable OLGAMANAGER ausgewertet. Dort kann ein kompletter Zugriffspfad stehen! Zunächst extrahiert man aus diesem Pfad einen Programmnamen für appl_find() und geht entsprechend wie unter dem ersten Punkt vor. Konnte auch dieser Name nicht gefunden werden, startet man das Programm, das von OLGAMANAGER bezeichnet wird, mit shel_write() nach.
    
3. Wenn das bisherige nicht zum Erfolg geführt hat, kann man die ersten beiden Punkte nochmal mit einem appl_find("OLEMANGR") bzw. der Environmentvariablen OLEMANAGER durchführen. Dieser Punkt ist aber mittlerweile obsolet und kann daher auch problemlos ignoriert werden.
    

Hat man die AES-ID des OLGA-Managers gefunden, wird dieser zunächst mit dem OLE-Protokoll initialisiert.

• 4.2.1 Nachstarten des OLGA-Managers
• 4.2.2 OLE_INIT
• 4.2.3 OLGA_INIT
• 4.2.4 OLE_EXIT
• 4.2.5 OLE_NEW

4.2.1 Nachstarten des OLGA-Managers

In diesem Abschnitt gibt es einen Algorithmus zum Finden bzw. Nachstarten des OLGA-Manager als Pseudo-Pascal-Code, der mit MagiC, MultiTOS etc. funktioniert.

OLGAManager:=appl_find('OLGA    ');

if (OLGAManager < 0) then
  begin
    envstr:=GetEnv('OLGAMANAGER');

    if (length(envstr) > 0) then
      begin
        // Dateinamen in Großbuchstaben und ohne Extension
        // aus envstr extrahieren
        datei:=StrPUpper(GetFilename(envstr,false));

        // Dateinamen evtl. mit Leerzeichen auffüllen, damit
        // der Name exakt acht Zeichen lang ist
        datei:=datei+StrPSpace(8-length(datei));

        OLGAManager:=appl_find(datei);

        if (OLGAManager < 0) then
          begin
            // der Manager läuft noch nicht, wir müssen
            // ihn also nachstarten

            OLGAManager:=StartApp(datei);
          end
      end
  end;

if (OLGAManager >= 0) then
  begin
    // OLE_INIT an OLGAManager schicken
  end;

function StartApp(prg: string): integer;

  begin
    ret:=-1;

    if (MultiTOS or MagiC) then
      if (Exist(prg)) then
        begin
          if MagiC then ret:=shel_write(1,100,@prg,NULL)
          else
            ret:=shel_write(0,1,@prg,NULL);
        end;

    StartApp:=ret;
  end;

4.2.2 OLE_INIT

Hat man einen (bzw. zwei, s.o.) Manager gefunden, schickt man ihm folgende Message:

OLE_INIT
(Client/Server -> Manager)
msg[0] $4950 (18768)
msg[1] apID
msg[2] 0
msg[3] Bitmap, OL_SERVER und/oder OL_CLIENT gesetzt, OL_IDLE
msg[4] max. von der App. verstandene Stufe des Protokolls
       (z.Z. immer 0)
msg[5] reserviert (auf 0 setzen)
msg[6] reserviert (auf 0 setzen)
msg[7] maschinenlesbarer XAcc-Programmtyp (oder 0):
             "WP" = Textverarbeitung
             "DP" = DTP
             "ED" = Texteditor
             "DB" = Datenbank
             "SS" = Tabellenkalkulation
             "RG" = Rastergrafikprogramm
             "VG" = Vektorgrafikprogramm
             "GG" = allgemeines Grafikprogramm
             "MU" = Musikanwendung
             "MV" = Movie/Video
             "CD" = CAD
             "DC" = Datenkommunikation
             "DT" = Desktop
             "PE" = Programmierumgebung

OL_SERVER = $0001   Applikation ist OLGA-Server
OL_CLIENT = $0002   Applikation ist OLGA-Client
OL_PEER   = $0003   Applikation ist Client und Server
OL_IDLE   = $0800   Applikation unterstützt den Idle-Test
OL_PIPES  = $1000   Applikation möchte nicht über Pointer, sondern
                    über MTOS-D&D-Pipes kommunizieren; der Manager
                    meldet dann, ob er diese Kommunikation beherrscht
                    bzw. ob sie auf dem aktuellen System möglich ist
                    (s.u.); das Verfahren wird z.Z. noch nicht unter-
                    stützt, eine genauere Definition folgt später

Daraufhin erhält man vom Manager eine OLGA_INIT-Message.

4.2.3 OLGA_INIT

Der OLGA-Manager verschickt als Bestätigung die OLGA_INIT-Message. Wichtig: Applikationen sollten den OLGA-Mechanismus erst verwenden, nachdem sie folgende Message erhalten haben und diese keinen Fehler signalisiert hat (für Applikationen, die während der Startphase Dokumente öffnen, kann es sinnvoll sein, auch ohne empfangene OLGA_INIT-Message die nötigen OLGA-Messages zu verschicken, nur sollten bei der Applikation keine Fehlfunktionen auftreten, falls sich der Manager doch nicht meldet).

OLGA_INIT
(Manager -> Client/Server)
[0] $1236 (4662)
[1] apID
[2] 0
[3] Bitmap, OL_MANAGER+OL_START+OL_IDLE+OL_CONF gesetzt
[4] Stufe des verwendeten (!) Protokolls (z.Z. immer 0)
[5] 0
[6] 0
[7] 0=Fehler, sonst: OL-Mechanismus verfügbar

OL_CONF    = $0400   Manager unterstützt OLGA_GETSETTINGS
OL_IDLE    = $0800   Manager unterstützt den Idle-Test
OL_PIPES   = $1000   Manager verwendet zur Kommunikation MTOS-D&D-
                     Pipes (nur nach Anforderung, s.o., wird z.Z.
                     noch nicht unterstützt und ist daher nie
                     gesetzt!)
OL_START   = $2000   Manager kann OLGA_START ausführen
OL_MANAGER = $4000   Applikation ist der OLGA-Manager

4.2.4 OLE_EXIT

Beim Programmende wird dem Manager folgende Message geschickt (die Nachricht wird außerdem von Manager an die Applikationen verschickt, sollte dieser terminieren). Wenn sich ein OLGA-Client abmeldet, werden automatisch alle zugehörigen Links und Documents gelöscht.

OLE_EXIT
(Client/Server -> Manager, Manager -> Client/Server)
msg[0] $4951 (18769)
msg[1] apID
msg[2] 0
msg[3] 0
msg[4] 0
msg[5] 0
msg[6] 0
msg[7] 0

4.2.5 OLE_NEW

Wenn ein Manager nachgestartet wird, verschickt er an alle erreichbaren Applikationen folgende Message:

OLE_NEW
(Manager -> Client/Server)
msg[0] $4952 (18770)
msg[1] apID
msg[2] 0
msg[3] Bitmap (OL_MANAGER, OL_START, OL_IDLE, OL_CONF)
msg[4] max. Manager-Stufe des OLGA-Protokolls
msg[5] reserviert (auf 0 setzen)
msg[6] reserviert (auf 0 setzen)
msg[7] Versionsnummer des Managers, z.B. $0114 für 1.14

Nach Empfang und Auswertung dieser Message sollte eine Applikation OLE_INIT verschicken. Die Werte in OLE_NEW ersetzen nicht die Rückgabe von OLGA_INIT, sie dienen nur zu Informationszwecken!

4.3 ...aus der Sicht des Servers

• 4.3.1 OLGA_UPDATE
• 4.3.2 OLGA_GETINFO
• 4.3.3 OLGA_INFO
• 4.3.4 OLGA_RENAME
• 4.3.5 OLGA_BREAKLINK
• 4.3.6 OLGA_CLIENTTERMINATED

4.3.1 OLGA_UPDATE

Wenn der Server irgend eine Datei abgespeichert hat, wird an den OLGA-Manager folgende Message geschickt: (Die Groß-/Kleinschreibung des Dateinamens wird im Moment ignoriert, damit das Linking nicht an unterschiedlichen Benutzereingaben scheitert; auf erweiterten Filesystemen wird das später allerdings nicht mehr so sein.)

OLGA_UPDATE
(Server -> Manager)
[0] $1238 (4664)
[1] apID
[2] 0
[3]
 +  Pointer auf den kompletten Dateinamen incl. (absolutem!) Pfad
[4]
[5] 0 bzw. Server-interne (eindeutige) Index-Nummer, falls eine Info-Datei
    zur Verfügung steht oder erzeugt werden kann (s. OLGA_GETINFO)
[6] 0
[7] 0

Als Antwort erhält der Server folgende Message, worauf er z.B. allozierten Speicherplatz für den Dateinamen wieder freigeben kann:

OLGA_ACK
(Manager -> Server)
[0] $1239 (4665)
[1] apID
[2] 0
[3]
 +  exakt dieselben Wert von OLGA_UPDATE
[4]
[5] 0
[6] 0
[7] OLGA_UPDATE

4.3.2 OLGA_GETINFO

Wenn der Server bei OLGA_UPDATE eine Index-Nummer für eine Info-Datei bekanntgegeben hat, kann ein Client (!) letztere nun direkt beim Server abfragen. Nach dem Empfangen von OLGA_GETINFO kann der Server eine solche Datei erzeugen (Aufbau s.u.), falls sie noch nicht existiert. Zu beachten ist, daß die übergebene Index-Nummer nicht gültig sein muß, die OLGA_GETINFO-Message muß dann vom Server ignoriert werden!

OLGA_GETINFO
(Client -> Server)
[0] $1247 (4679)
[1] apID
[2] 0
[3] 0
[4] 0
[5] Index-Nummer der gewünschten Info-Datei
[6] 0
[7] 0

4.3.3 OLGA_INFO

Als Antwort auf OLGA_GETINFO verschickt der Server direkt an den Client (!) folgende Message (nachdem die Info-Datei erzeugt wurde - falls sie nicht sogar ständig vorhanden ist).

OLGA_INFO
(Server -> Client)
[0] $1248 (4680)
[1] apID
[2] 0
[3]
 +  Pointer auf den kompletten Info-Dateinamen incl. (absolutem!) Pfad
[4]
[5] Index-Nummer der gewünschten Info-Datei
[6] 0
[7] 0

Der Client darf sich allerdings nicht auf eine solche Antwort verlassen, der Server könnte ja mittlerweile terminiert haben. Außerdem darf der Client nur lesend auf die Datei zugreifen.

Sobald der Client die Datei wieder geschlossen hat, teilt er dies dem Server direkt (!) mit, damit dieser die Datei evtl. wieder löschen kann.

OLGA_ACK
(Client -> Server)
[0] $1239 (4665)
[1] apID
[2] 0
[3]
 +  exakt dieselben Werte von OLGA_INFO
[4]
[5] Index-Nummer der gewünschten Info-Datei
[6] 0
[7] OLGA_INFO

4.3.4 OLGA_RENAME

Wenn der Benutzer eine Datei im Server umbenennt (oder verschiebt!), schickt der Server dem Manager die OLGA_RENAME-Message. Es liegt im Ermessen des Servers, ob er nach "Speichern als..." eine solche Message verschickt (das hängt z.B. auch davon ab, ob der Server selbst die neue Pfadangabe bzw. den neuen Dateinamen für das bestehende Dokument übernimmt); nach Möglichkeit sollten Links aber immer nur für Dateien auf nicht wechselbaren Medien bestehen (A: und B: sind also denkbar schlechte Kandidaten). Wenn zusätzlich der Dateiinhalt verändert wurde, muß nach der OLGA_RENAME-Message außerdem noch eine OLGA_UPDATE-Message verschickt werden!

OLGA_RENAME
(Server -> Manager)
[0] $123a (4666)
[1] apID
[2] 0
[3]
 +  Pointer auf den alten Dateinamen incl. absolutem Pfad
[4]
[5]
 +  Pointer auf den neuen Dateinamen incl. absolutem Pfad
[6]
[7] 0

Als Antwort erhält der Server wiederum eine Message, die er z.B. zum Freigeben des alten Speicherplatzes verwenden kann. Diese Bestätigung bedeutet allerdings nur, daß der Manager das Umbenennen weitergemeldet hat, wenn ein Client nicht darauf reagiert, ist der entsprechende Link dann "tot".

OLGA_ACK
(Manager -> Server)
[0] $1239 (4665)
[1] apID
[2] 0
[3]
 +  exakt dieselben Wert von OLGA_RENAME
[4]
[5]
 +  exakt dieselben Wert von OLGA_RENAME
[6]
[7] OLGA_RENAME

4.3.5 OLGA_BREAKLINK

Sollte der Server eine Datei löschen (oder anderweitig für den Client unbrauchbar machen), muß er dies dem Manager mit folgender Message mitteilen. Der Manager verständigt dann alle Clients, die einen Link auf diese Datei gesetzt hatten.

OLGA_BREAKLINK
(Server -> Manager)
[0] $1244 (4676)
[1] apID
[2] 0
[3]
 +  Pointer auf den Dateinamen incl. absolutem Pfad
[4]
[5] 0
[6] 0
[7] 0

Auch hierauf verschickt der Manager eine Antwort an den Server:

OLGA_ACK
(Manager -> Server)
[0] $1239 (4665)
[1] apID
[2] 0
[3]
 +  exakt dieselben Wert von OLGA_BREAKLINK
[4]
[5] 0
[6] 0
[7] OLGA_BREAKLINK

4.3.6 OLGA_CLIENTTERMINATED

Wenn ein Client terminiert, der einen Server per OLGA_START aufgerufen hat, erhält dieser Server folgende Message:

OLGA_CLIENTTERMINATED
(Manager -> Server)
[0] $1255 (4693)
[1] manID
[2] 0
[3] AES-ID des terminierten Clients
[4] Anzahl der Clients, die den Server noch benutzen (>=0)
[5] 0
[6] 0
[7] 1, wenn der Server bei OLGA_START schon lief; 0 sonst

4.4 ...aus der Sicht des Clients

• 4.4.1 OLGA_OPENDOC
• 4.4.2 OLGA_CLOSEDOC
• 4.4.3 OLGA_LINK
• 4.4.4 OLGA_UNLINK
• 4.4.5 OLGA_UPDATED
• 4.4.6 OLGA_RENAMELINK
• 4.4.7 OLGA_LINKRENAMED
• 4.4.8 OLGA_LINKBROKEN
• 4.4.9 OLGA_START
• 4.4.10 OLGA_SERVERTERMINATED

4.4.1 OLGA_OPENDOC

Wenn ein OLGA-Client ein Dokument öffnet (egal ob schon bestehend oder neu), kann (!) dem OLGA-Manager folgende Message geschickt werden. Sie dient z.Z. nur zu Informationszwecken, die benötigten internen Strukturen werden vom Manager ansonsten beim Empfangen der ersten OLGA_LINK-Message angelegt. Die Gruppenkennung sollte allerdings trotzdem (wenn auch nur Client-intern) festgelegt werden, da sie für die Links benötigt wird.

OLGA_OPENDOC
(Client -> Manager)
[0] $123b (4667)
[1] apID
[2] 0
[3] 0
[4] 0
[5] Gruppenkennung (eine innerhalb des Clients eindeutige, vom Client
    frei wählbare Zahl, mit der die Links innerhalb des Clients den
    Dokumenten zugeordnet werden können)
[6] 0
[7] 0

Als Antwort erhält der Client folgende Message:

OLGA_ACK
(Manager -> Client)
[0] $1239 (4665)
[1] apID
[2] 0
[3] 0
[4] 0
[5] Gruppenkennung des Dokuments
[6] 0
[7] OLGA_OPENDOC

4.4.2 OLGA_CLOSEDOC

Schließt ein Client ein Dokument, das Links enthält, sollte dem OLGA-Manager folgende Message geschickt werden, die alle Links mit der entsprechenden Gruppenkennung löscht. Das kann zwar auch mit einzelnen OLGA_UNLINK-Aufrufen geschehen, aber so können Manager-interne Strukturen einfacher freigegeben werden (außerdem ist es einfacher für den Programmierer :-). Darf beim Programmende nicht verwendet werden, da OLE_EXIT alle Documents löscht.

OLGA_CLOSEDOC
(Client -> Manager)
[0] $123c (4668)
[1] apID
[2] 0
[3] 0
[4] 0
[5] Gruppenkennung des Dokuments
[6] 0
[7] 0

Als Antwort erhält der Client folgende Message:

OLGA_ACK
(Manager -> Client)
[0] $1239 (4665)
[1] apID
[2] 0
[3] 0
[4] 0
[5] Gruppenkennung des Dokuments
[6] 0
[7] OLGA_CLOSEDOC

4.4.3 OLGA_LINK

Mit der folgendes Message teilt ein Client dem Manager mit, daß eine Datei in eines seiner Dokumente eingebunden wurde - allerdings in der Form, daß nur eine Referenz (hier der Dateiname mit absolutem Pfad) gespeichert wird. Wenn diese Datei von einem OLGA-Server verändert wird (oder eine AV_PATH_UPDATE-Message von einem Programm empfangen wird, das kein Server ist), erhält der Client dann eine OLGA_UPDATED Message.

OLGA_LINK
(Client -> Manager)
[0] $123d (4669)
[1] apID
[2] 0
[3]
 +  Pointer auf den Dateinamen, der überwacht werden soll
[4] (incl. absolutem Pfad)
[5] Gruppenkennung des Dokuments (s. OLGA_OPENDOC)
[6] 0
[7] 0

Als Bestätigung verschickt der Manager folgende Message:

OLGA_ACK
(Manager -> Client)
[0] $1239 (4665)
[1] apID
[2] 0
[3]
 +  exakt dieselben Wert von OLGA_LINK
[4]
[5] Gruppenkennung des Dokuments
[6] 0=Fehler, sonst: Link eingerichtet
[7] OLGA_LINK

4.4.4 OLGA_UNLINK

Soll die Überwachung für eine Datei beendet werden, muß der Client dem Manager folgende Message schicken. Beim Schließen eines Dokuments sollte stattdessen allerdings OLGA_CLOSEDOC verwendet werden, beim Beenden der Client-Applikation werden die Links mit OLE_EXIT automatisch gelöscht.

OLGA_UNLINK
(Client -> Manager)
[0] $123e (4670)
[1] apID
[2] 0
[3] Pointer auf den Dateinamen (incl. absolutem Pfad), der nicht mehr
 +  überwacht werden soll (muß exakt mit der Zeichenkette aus OLGA_LINK
[4] übereinstimmen)
[5] Gruppenkennung des Dokuments
[6] 0
[7] 0

Als Bestätigung erhält der Client folgende Message:

OLGA_ACK
(Manager -> Client)
[0] $1239 (4665)
[1] apID
[2] 0
[3]
 +  exakt dieselben Wert von OLGA_UNLINK
[4]
[5] Gruppenkennung des Dokuments
[6] 0=Fehler, sonst: Link entfernt
[7] OLGA_UNLINK

4.4.5 OLGA_UPDATED

Und mit der nächsten Message werden dem Client Änderungen an einer Datei vom Manager mitgeteilt! Wenn der Client also eine solche Message empfängt, sollte das zugehörige Dokument neu angezeigt werden. Der Pointer ist solange gültig, wie der Link besteht.

OLGA_UPDATED
(Manager -> Client)
[0] $123f (4671)
[1] apID
[2] 0
[3]
 +  Pointer auf den Dateinamen (incl. absolutem Pfad) der Datei,
[4] die verändert wurde
[5] 0 bzw. Index-Nummer, falls eine Info-Datei angefordert werden kann
[6] apID des Updaters (Server); garantiert gesetzt, wenn [5] ungleich null;
    an diese ID kann eine OLGA_GETINFO-Message geschickt werden
[7] Gruppenkennung des Dokuments

Wenn dem Client bei dieser Message das Vorhandensein einer Info-Datei (Aufbau s.u.) gemeldet wird und der Client diese anfordern möchte, sollte er so schnell wie möglich dem Server direkt (!) eine OLGA_GETINFO-Message schicken. Dieses Vorgehen ist bereits weiter oben ("...aus der Sicht des Servers") beschrieben.

4.4.6 OLGA_RENAMELINK

Wenn ein Server eine Datei umbenannt oder verschoben hat, erhält der Client folgende Message. Sie dient nur dazu, daß der Client seine interne Referenz aktualisiert, d.h. das Dokument muß nicht neu gezeichnet werden! Der Pointer auf den neuen Namen ist solange gültig, wie der Link besteht.

OLGA_RENAMELINK
(Manager -> Client)
[0] $1240 (4672)
[1] apID
[2] 0
[3]
 +  Pointer auf den alten Dateinamen incl. absolutem Pfad
[4]
[5]
 +  Pointer auf den neuen Dateinamen incl. absolutem Pfad
[6]
[7] Gruppenkennung des Dokuments

4.4.7 OLGA_LINKRENAMED

Als Antwort auf OLGA_RENAMELINK muß der Client an den Manager folgende Message schicken, damit letzterer seine Referenz aktualisiert und unnötigen Speicherplatz freigibt (der Client muß dazu nur die Messagenummer austauschen). Unterbleibt diese Antwort, ist der entsprechende Link "tot", kann also nicht mehr überwacht werden (da ja im Manager dann noch der alte Name gespeichert ist).

OLGA_LINKRENAMED
(Client -> Manager)
[0] $1241 (4673)
[1] apID
[2] 0
[3]
 +  Pointer auf den alten Dateinamen incl. absolutem Pfad
[4]
[5]
 +  Pointer auf den neuen Dateinamen incl. absolutem Pfad
[6]
[7] Gruppenkennung des Dokuments

4.4.8 OLGA_LINKBROKEN

Wenn eine Datei dem Client plötzlich nicht mehr zur Verfügung steht (z.B. weil sie gelöscht wurde), wird dies vom Manager mit folgender Message mitgeteilt. Der Client kann daraufhin z.B. den Benutzer informieren oder per Fileselectbox eine andere Datei auswählen lassen.

OLGA_LINKBROKEN
(Manager -> Client)
[0] $1245 (4677)
[1] apID
[2] 0
[3]
 +  Pointer auf den Dateinamen incl. absolutem Pfad
[4]
[5] Gruppenkennung des Dokuments
[6] 0
[7] 0

Außerdem sollte der Client den jetzt ungültigen Link mit der normalen Unlink-Message auflösen:

OLGA_UNLINK
(Client -> Manager)
[0] $123e (4670)
[1] apID
[2] 0
[3] Pointer auf den Dateinamen (incl. absolutem Pfad), der nicht mehr
 +  überwacht werden kann (es können auch exakt die Werte aus
[4] OLGA_LINKBROKEN übergeben werden!)
[5] Gruppenkennung des Dokuments
[6] 0
[7] 0

4.4.9 OLGA_START

Für Clients bietet der Manager eine einfache Möglichkeit, passende Server nachzustarten bzw. aufzurufen. Dazu wird (bei OLS_TYPE und OLS_EXTENSION) die Datei OLGA.INF ausgewertet. Zunächst wird der darin gefundene Server im Speicher gesucht und bei Erfolg mit VA_START (s. Gemini-Doku) aufgerufen. Ansonsten wird das Programm unter MultiTOS bzw. MagiC mit shel_write() nachgestartet.

OLGA_START
(Client -> Manager)
[0] $1246 (4678)
[1] apID
[2] 0
[3] eine der OLS-Konstanten (s.u.)
[4]
 +  Angaben, welches(r) Programm(typ) gestartet werden soll
[5] (abhängig von [3], s.u.)
[6]
 +  Pointer auf Kommandozeile (i.A. die zu ladende Datei) oder NULL
[7]

OLS_TYPE      = $0001  [4]=0, in [5] steht ein XAcc-Programmtyp
OLS_EXTENSION = $0002  in [4]+[5] steht eine Extension (z.B. ".GEM")
OLS_NAME      = $0003  in [4]+[5] steht ein Pointer auf den absoluten
                       Dateinamen der zu startenden Applikation

Als Bestätigung erhält man folgende Message:

OLGA_ACK
(Manager -> Client)
[0] $1239 (4665)
[1] apID
[2] 0
[3] OLS-Konstante von OLGA_START
[4]
 +  exakt dieselben Wert von OLGA_START
[5]
[6] 0=Fehler, sonst: Server gestartet
[7] OLGA_START

Um die Kommandozeile leichter freigeben zu können, erhält man außerdem noch eine zweite Message (wenn für die Kommandozeile nicht NULL übergeben wurde).

OLGA_ACK
(Manager -> Client)
[0] $1239 (4665)
[1] apID
[2] 0
[3] 0 (!)
[4]
 +  exakt dieselben Wert von OLGA_START [6]+[7]
[5]
[6] 0=Fehler, sonst: Server gestartet
[7] OLGA_START

4.4.10 OLGA_SERVERTERMINATED

Wenn ein Server terminiert, erhalten alle Clients, die diesen Server per OLGA_START aufgerufen haben, folgende Message:

OLGA_SERVERTERMINATED
(Manager -> Client)
[0] $1254 (4692)
[1] manID
[2] 0
[3] AES-ID des terminierten Servers
[4]
 +  Extension oder (0,XAcc-Typ) oder NULL
[5]
[6] reserviert
[7] 0

Je nachdem, in welchem Modus der Server nachgestartet wurde, enthalten die Felder [4..5] unterschiedliche Werte. Beim Start mit OLS_EXTENSION steht dort eben diese Extension, beim Start mit OLS_TYPE ist [4]=0 und [5] enthält den XAcc-Programmtyp. Beim Start mit OLS_NAME sind beide Felder ausgenullt.