* Idee: MAX - Multicast Alarm Extension. Eigener Prozess auf VMS,
  der die via Multicast verschickten Alarme empfängt, sie in ein
  NetmanPacket verpackt (iiiigitttt!) und sie einfach in die 
  Empfangsmailbox von CAP schiebt. Das hat den Vorteil, dass MAX
  ziemlich simpel bleibt und man trotzdem die komplette Funktionalität
  von CAP nutzt. Benutzerprogramme bleiben dadurch völlig unberührt.
  Sie können sofort Alarme von PPC-GuPs empfangen.

-> Ok!


* Mehrere Alarme in einem Multicast-Paket? Auf jeden Fall
  sollte der MAX schon weitgehend so gebaut werden, dass er
  mehrere Alarme in einem Paket verarbeiten kann. Für die
  Weitergabe der Alarme an CAP via NetmanPacket ist das eh 
  notwendig.

-> Ok! MAX ist so gebaut, dass er _ein_ Multicast-Alarmpaket
  (McastAlarmpacketType) empfängt. Dieses enthält das bisher 
  übliche Alarmpaket (AlarmpacketType), welches wiederum 
  mehrere Alarme enthalten kann.


* Festlegen einer "Multicast Group". Mitglieder sollten sein
  axp7xx, axp3xx, asl7xx, asl3xx, PPC-GuPs. Wer eventuell noch?

-> Ok! Sie, bzw. der Host, heißt "alarm-mcast[.acc.gsi.de]"


* Muss auch eine Portnummer festgelegt werden?

-> Ok! Der Service (Port) heißt "AccAlarm"


* Floats in Alarmen, die von PPC-GuPs geschickt werden, sind
  im IEEE-Format (SISDataType "Real_t"), im Gegensatz zu 
  Alarmen von M68K-GuPs, deren Floats im FFLOAT- bzw. GFLOAT-
  Format (SISStatType "RealF" bzw. "RealG") sind.
  - Beim Zusammenbauen eines Alarms auf PPC-Ebene sollte das
    Setzen des Typs irgendwie automatisch gehen, weil "Real_t"
    nicht mehr so ganz die passende Bezeichnung ist.
  - MAX sollte beim Empfang von Alarmen mit Floats nur "Real_t"
    akzeptieren und "RealF", "RealG" mit einem Fehler abweisen.
  Im Prinzip könnte man auch die VMS-Formate vom PPC-GuP aus
  verschicken. Das macht aber wenig Sinn, weil die Alarme ja
  auch von Linux-Rechnern auf der Operating-Ebene empfangen
  werden sollen.
  Was ist, wenn man von einem PPC einen Alarm mit Float64 
  verschicken will? Dann müssen wir einen weiteren SISDataType
  erfinden, etwa "IEEEFLOAT64" - und in diesem Zuge womöglich 
  "Real_t" in IEEEFLOAT32 umbenennen.

-> Ok! So isses im Prinzip.


* Es existieren zwei verschiedene Dateien capaccess.h. Einmal
  mit Deklaration der ganzen Funktionen, wie z.B. readAlarm(),
  und einmal ohne diese. Zudem werden manche Typen unterschiedlich
  geschrieben, einmal AlarmType, einmal Alarm_Type. Dann gibt
  es noch unterschiedlich viele Align-Typen und mehr oder weniger
  Strukturelemente aus diesen Typen. Das muss alles vereinheitlicht 
  werden. Siehe sis_inc:capaccess.h und sis_inc:capaccess.h-save
  (auf VMS) für die unterschiedlichen Includes.

  Anscheinend kann man ohne Alignment-Probleme das sis_inc:capaccess.h 
  (VMS) benutzen. Jedenfalls ging das mit convert-alarm.c und max.c.
  In diesem capaccess.h gibt es kein "#ifdef CADUL" usw. mehr. Das 
  kann man noch in sis_inc:capaccess.h-save nachgucken.

-> Auf VMS-Client-Seite erledigt. Auf asl-Client- und PPS-Server-Seite 
   wurde capaccess.h in alarm.hh eingearbeitet.


* In capaccess.h gibt es für Status-Alarm und Active-Alarm die
  Elemente `old' und `new'. Mit C++ geht `new' nicht mehr als
  Elementname, da das ein reserviertes Wort ist. Stattdessen
  muss man wohl `act' oder sowas nehmen. Das geht allerdings
  nicht mehr auf VMS, da dort zu viele Programme betroffen sind.

  Wie sieht es für die GSW aus? Dort muss man beim Umzug von
  lbg nach asl die Änderung machen. Da aber Alarme in der 
  Regel von USRs verschickt werden, die eh angepasst werden
  müssen, sollte das kein großes Problem sein.

-> Ok!


* In alarm-support.cc (zur Zeit auf ~hechler/alarm) ist die
  Klasse SendAlarm nun als Singleton implementiert. Damit sie
  thread-safe ist, muss die Methode instance() mit einem Lock
  versehen werden. Dieser ist zur Zeit ein OmniORB-Lock, womit
  SendAlarm CORBA-abhängig geworden ist. Es stellt sich die
  Frage, ob man OmniORB-Locks verwenden muss, wenn man mit
  OmniORB arbeitet? Die wurden ja nicht umsonst entwickelt.
  Ist das so, dann müsste man bei Gelegenheit wieder kunstvoll 
  diese Abhängigkeit verstecken. Im Prinzip sollte man nämlich 
  SendAlarm auf allen Plattformen (außer VMS?) benutzen können. 

  Die Testanwendung sndalarm.cc läuft zur Zeit noch nicht mit
  Threads. Ob SendAlarm also tatsächlich zusammen mit Threads
  tut wie gedacht, ist noch nicht getestet. Mit der ganz 
  einfachen Anwendung sndalarm.cc geht's aber problemlos.

-> Ok! Es gibt einen IP-AlarmTransceiver, der das richtig macht.


* AlarmHandler ist nun ein Singleton. Es gibt ihn also nur einmal in einer
  Anwendung (mit mehreren Threads). Sage ich jetzt also "SET TK1MU1(SHUTUP)=1",
  dann werden nicht nur die Alarme von TK1MU1 abgeschaltet, sondern die Alarme
  _aller_ Geräte. So will das aber keiner haben.

-> Ok! Der IP-AlarmTransceiver, macht das schon richtig.