* Wir haben kurz diskutiert, ob es beim Ein- und Ausschalten
  von Alarmen (Property SHUTUP) einen Alarm geben soll, der
  genau dieses meldet. Wenn ja, dann ist die Frage, ob das ein 
  Konfigurationsalarm werden soll. Der ConfigAlarm würde dann 
  um die Elemente AlarmsDisabled und AlarmsEnabled erweitert.
  Vorstellbar ist aber auch, dass man einfach einen einfachen
  Message-Alarm (DevSpec-, ProcSpec-, System-Alarm) nimmt und
  diesen die Messages CAP$_ALARMSDISABLED und CAP$_ALARMSENABLED
  verschicken läßt. 

  Perspektivisch müsste natürlich jede Einheit, und nicht nur 
  Geräte, bei der das Verschicken von Alarmen abschaltbar ist,
  diese Alarme verschicken.


* Wir wollten mal die Gerätemodellnummer im Alarm haben, damit man z.B. 
  einfach alle MX-Alarme sammeln kann. Diese Nummer macht aber keinen Sinn, 
  wenn der Alarm z.B. von SD oder PZSUZY kommt. Also sollte dieses Element 
  im Alarm eine allgemeinere Bedeutung haben. Dann kann man es auch noch 
  für andere Infos nutzen.

  Erster Ansatz: Ich beschreibe in einem Element, welche Bedeutung das 
  folgende Element hat. Das sähe z.B. so aus:
 
    typedef enum {
      NotSet, EqModelNo, ProcessId, WhatSoEver, Etc, ...,
    } IdDescriptor;

    typedef struct IdType {
      IdDescriptor descriptor;
      ULong id
    } IdType;

    typedef struct AlarmType {
      ...
      IdType id;
      ...
    } AlarmType;

  Für einen Alarm von TK1MU1 hätte man dann als id.descriptor = EqModelNo 
  und als id.id = 19, die Gerätemodellnummer für MX.

  Man kann sich aber leicht vorstellen, mehrere Infos haben zu wollen, 
  z.B. "EqModelNo" und "Therapy", wenn man etwa auf alle Therapie-Alarme 
  hören will. Aber dann wird's gleich ziemlich unübersichtlich und hässlich:

  Nimmt man descriptor als Bitset, so dass jedes einzelen Bit eine Bedeutung 
  hat, dann kann man mehrere parallel setzen. Für manche Bits braucht man 
  dann eine eigene ID, z.B. für EqModelNo, für andere wiederum nicht, etwa 
  für das Bit "Therapy" (also "Ulong id[17]"). 

  Dann muss man noch genau auf die Reihenfolge achten in der "id" gefüllt 
  wird. Man muss ja sicherstellen, dass, wenn "EqModelNo" und "WhatSoEver" 
  parallel kommen, in id[0] immer die Gerätemodellnummer steht und in id[1] 
  immer die WhatSoEver-ID.

  Man könnte auch sagen, immer 17 "id"s mitzuschicken, wo meist nur die erste 
  eine Bedeutung hat, ist auch nicht schön. Aber eine variable Anzahl mit 
  extra Counter, der angibt wieviele gerade mitgeschickt werden, 
  ist auch nicht besser.

  Und letztenendes muss man noch die ganze Problematik der Filterung dieser 
  Alarme bedenken. Wie kann der Anwender vernünftig einen Filter spezifizieren 
  und wie kann CAP in angemessener Zeit die Filterung vornehmen.