[Allegro] Hochfrequente Mehrfachfelder : Neue Lösung gesucht

[Bernhard Eversberg]

Hochfrequente Mehrfachfelder  (HMF)

allegro punktet mit dem Feature der beliebig häufigen Feldwiederholung,
und dies ohne daß man es eigens konfigurieren muß.
"Beliebig" ist allerdings in diesem Fall kein dehnbarer Begriff! Es
gibt Grenzen, und die sind in manchen Spezialfällen schon unangenehm
aufgestoßen. Denn jedes Mehrfachfeld braucht ein eindeutiges Zeichen,
das an die Feldnummer angehängt wird. Die Wiederholung geht also
nicht, wie Uneingeweihte denken mögen, so vor sich, daß man etwa
eingeben könnte:

#40 Name1
#40 Name2
#40 Name3
...

sondern es hat zu lauten

#40 Name1
#402Name2
#403Name3
...

und statt 2 und 3 kann es auch lauten 0 und 1 oder 1 und 9 oder
a und b oder X und Y usw. - Die Zeichen müssen nur eindeutig sein,
d.h. zweimal #40a in einem Satz geht nicht.
[Für die Zwecke der Parametrierung ist es natürlich hilfreich,
wenn man die verwendbaren Zeichen einheitlich verwendet und nicht
beim einen Satz so und beim nächsten wieder anders.]

Vorweg: Hier soll es nur um die Frage der echten Feldwiederholung
gehen, nicht um Mehrfacheinträge *innerhalb* eines Feldes, getrennt
durch " ; " oder was immer! Die bleiben unberührt. Das Verfahren ist
zwar auch ein Vorzug von allegro, wäre aber kein vollwertiger Ersatz
für die echten Mehrfachfelder, schon wegen der Proleme mit den
Unterfeldern, die sich dann ergeben.

Nun umfassen Ziffern und Buchstaben zusammen 62 Zeichen, d.h. 63
mögliche Besetzungen z.B. des Feldes #40. Reicht dies nicht, und
das kommt eben vor, dann können auch Sonderzeichen verwendet werden.
Die Zeichencodes jenseits 126 und unterhalb 32 sind jedoch mit einiger
Vorsicht zu genießen, vor allem dann, wenn man von PRESTO zu a99
übergeht, d.h. da ist's noch relativ unproblematisch, aber definitiv
dann, wenn man zu UTF-8 übergehen will. Und das ist ein oder der
Hauptgrund für diese Erörterung!

Wichtig zu wissen, und daran ist nicht zu rütteln (nein, wirklich
nicht, sorry): Als Wiederholungszeichen kann kein echter UTF-8-Code
verwendet werden, also ein 2- oder 3-Byte Code (von 4 zu schweigen).
Großen ist die Kalamität daher dann, wenn man bisher Codes hat, die
jenseits 128 liegen, denn die können Bestandteil von UTF-8-Codes sein,
wären es ab der Position aber nicht. Intern, speichertechnisch, wäre
das noch immer unproblematisch, aber wenn es an die Oberfläche geht,
an das Parametrieren also, dann ist Holland in Not, aber auch das
Eingeben und Bearbeiten der Daten wird unerquicklich.

Mißlich ist das Verwenden von Codes jenseits 126 auch dann, wenn
es an die Parameter, die FLEXe oder auch die CFG geht. Das sind
ja simple Textdateien, und die Sonderzeichen werden von den
Editoren zum Teil stümperhaft behandelt oder verschandelt.
Wir hatten aus dem Grunde ja schon für die Parameter etc. neue
Möglichkeiten der Darstellung jener Zeichen eingeräumt (siehe Vb.257).
Wenn jedoch etwa ein Feld  #32ä  vorkommen sollte und man es in
einer Parameter- oder FLEX-Datei direkt ansprechen wollte, dann
ginge das noch immer nicht mit einer Ersatzcodierung, und wir wollen
das auch gar nicht erst einführen.

Damit stehen wir vor einem mißlichen Dilemma: Einserseits gibt es
Anwendungen, die mit dem bisherigen Potential noch gar nicht
auskommen, andererseits wird das Umgehen mit den bisherigen Codes
zu einer nur sehr schwer noch handhabbaren Aufgabe.

Die Diskussion zu dem Thema hatte bisher nicht zu umsetzbaren
Vorschlägen geführt. Wir machen daher einen neuen Ansatz, und der
sieht so aus:

1. Als Mehrfachcodes werden nur noch diese 62 Zeichen empfohlen:

     123456789@
     ABCDEFGHIJKLMNOPQRSTUVWXYZ
     abcdefghijklmnopqrstuvwxyz

     Damit kann man z.B. 63mal das Feld #40 haben in einem Satz.
     Ein paar mögliche Zeichen sind hier als "eiserne Reserve" noch
     ausgespart:  Die 0 und die Sonderzeichen

         !"#$%&')*+,-/   :;<=>   []^_

     Man könnte sie ohne weiteres hinzunehmen, nicht aber ( . und ~
     wegen deren Sonderfunktionen.

     Wenn's aber noch mehr sein soll, und darum geht's ja jetzt:

2. Man richtet zusätzliche Felder ein, empfohlen werden dafür
    Großbuchstaben, das ist aber nicht zwingend:

      #4A, #4B, #4C, ...   (ACHTUNG: #4A, nicht #40A !)

    In der CFG setzt man diese unter die #40, dann werden sie im
    Datensatz auch so sortiert, also vor der #41!
    Für jedes dieser Felder gibt es wieder bis zu 62 Wiederholungen.
    Soll die #41 ebenfalls so erweitert werden: #4E, #4F, ... unter
    die #41 einsetzen.

Damit hätte man ein Konstrukt, das keine allzu großen Probleme beim
Parametrieren machen würde, und das beim Editieren leichter als
bisher zu handhaben wäre. Keinerlei Programmänderung wäre nötig!

Was aber bliebe, wäre das Problem des Umstiegs auf dieses Konstrukt.
Man muß ja potentiell sehr viele Datensätze in die neue Form bringen,
d.h. die vorhandenen Mehrfachfelder umarrangieren, also z.B. das ä
in #40ä in zulässiger Weise ändern. Das riecht nach richtig viel
Arbeit, oder aber nach sehr schwieriger Parametrierung, d.h. dem
Schreiben einer sehr großen und diffizilen Parameterdatei.
Oder aber eines trickreichen FLEXes! Das ist der Weg, den wir im
Moment vorziehen würden und auf Machbarkeit schon ausgelotet haben.

Aber zuerst interessiert uns die Meinung der Anwenderschaft, und
vielleicht hat ja auch jemand einen noch besseren Vorschlag. Oder
setzt sich gleich hin, krempelt die Ärmel hoch, und schreibt den
FLEX. WM ist ja heute weniger interessant ...


B.E.