Fehler der Übersetzung

  Das vom Compiler generierte Modell war so leider nicht benutzbar. Zum Teil mag das daran liegen, daß eine Übersetzung einer MIB in eine Management-Anwendung prinzipiell nicht automatisch gehen kann. Stephen Heilbronner ist da der wohlbegründeten Ansicht, daß eine Management-Anwendung Bedeutungen benötigt, die sich nicht alleine aus der MIB ablesen lassen.

Doch scheitert die automatische Übersetzung in unserem Fall schon früher. Der Compiler erzeugt sogar DML-Code, der syntaktisch inkorrekt ist. Aktuell macht er dabei mindestens folgende Fehler:

1.

In der MIB hat jede Tabelle ein Index-Feld (z.B. stoIndex). Diese sind aber durchweg mit ACCESS not-accessible gekennzeichnet und der Agent erzeugt dazu keine Werte. Der MIB-Compiler aber legt ein entsprechendes Attribut an und die dazugehörende Query versucht das Feld zu lesen.

2.

In Abfragen für Tabellen wird die Reihenfolge der Attribute festgelegt, wie sie der Agent liefert (s. ). Bei den automatisch erzeugten Querys ist die Reihenfolge genau verkehrt.

3.

Das nichtterminale Symbol productionRHS der DML-Definition ist wie folgt festgelegt:

productionRHS ::=
    andProduction [ ('|' andProduction)* ]

Zum Teil aber generiert der Übersetzer Konstrukte der Form productionRHS mit einem zusätzlichen Zeichen | am Schluß.

Außerdem könnte der Compiler der MIB-Definition genauer genügen. Wie oben bemerkt, wird die Struktur der MIB für sehr abstrakte Objekte recht vage wiedergegeben: einige Objekte tauchen gar nicht auf und die erzeugten Objekte sind kaum verschachtelt. Dazu müsste aber wohl zuerst die Einschränkung zur unten () nochmal erwähnten Beziehung INA aufgehoben sein.