[Allegro] Vb.260: V34.3 ist da

Do Jul 10 09:03:53 CEST 2014

Verlautbarung 260 der Entw.Abt.                              2014-07-10
-------------------------------

V34.3 ist da
------------
             ... und zwar hier: ftp://134.169.20.101/inst-all.exe

HFM (Hochfrequente Mehrfachfelder)
==================================
[Rohentwurf erstmals vorgestellt am 23.6., nach Diskussion im Forum
  verfeinert und umgesetzt.]

Worum geht's?
-------------
Bisher konnte man Felder mehrfach besetzen, indem man an die Kategorie-
nummer ein Zeichen anhing, und zwar eine Ziffer, einen Buchstaben, und
auch fast alle Sonderzeichen waren möglich. Für beispielsweise ein
Feld #64 konnte man haben:  #641, #642, ... , #64A, #64a, #64ä usw.
Jedoch konnte man nicht zweimal oder öfter die #641 usw. verwenden,
sondern jede nur einmal. Damit waren maximal ca. 220 Belegungen zu
erreichen. Nicht wenig, aber nicht für alle Anwender genug! Hinzu kam
nun, daß die Sonderzeichen oberhalb ASCII 127 hinter der Kategorienummer
mit der internen Verwendung von Unicode nicht vereinbar waren. Deshalb
mußte und ist etwas geschehen:

Neu *hinzu* kommt folgende ganz einfache Möglichkeit:
An die Kategorienummer wird mit . eine Zahl gehängt, dann ein
Leerzeichen und dann der Inhalt, z.B.
   #64.1 Inhalt 1
   #64.2 Inhalt 2
   ...
   #64.300 Inhalt 300   usw.
und sogar 4- und 5-stellige Zahlen sind möglich. Die Zahlen brauchen
nicht lückenlos aufsteigend zu sein.
Entfallen hiermit  #641, #642 usw?? Keineswegs! Die können so bleiben,
man muß nichts daran ändern, wenn man nicht ausdrücklich so will. Oben
steht ja: die neue Möglichkeit *kommt hinzu* - nichts wird ungültig.

Aber mehr zu den Einzelheiten weiter unten, zuerst noch ein paar

Vorbemerkungen
--------------

ACHTUNG: Wer keine Probleme mit Mehrfachfeldern hat, braucht nichts
zu tun und diesen Beitrag nicht zu lesen! Das trifft zu für alle
Standard-Anwender, denn normale Katalogdaten sind völlig unkritisch.
Solche Anwender können auch die nächsten Versionen (V34.4 und
später) unbekümmert installieren und einfach weiterarbeiten.
Insbes. Anwender der Standardparameter mit $a.cfg brauchen nichts
zu ändern oder zu beachten: Version installieren und fertig - mit den
eigenen Daten passiert dabei nichts.

   http://www.allegro-c.de/aktuelle-version/a99hfm.zip

Das hier beschriebene gilt ab V34.3 für alle Programme, auch für die
Quadriga-Programme (atools) und PRESTO. Was zu den FLEX-Befehlen
gesagt wird, betrifft nur a99, alcarta und acon.

Ein universeller FLEX  hfmu.flx  wurde geschrieben, mit dem man
vorhandene Daten, mit individuellen Modifikationen, umwandeln kann.
(Der FLEX enthält ausreichend Kommentar.) Mehr siehe unten.

Es kommt dann evtl. noch auf die Parameter an, ob und wie für
einzelne Feldern für Anzeige, Index oder Exporte etwas zu ändern ist.
Man braucht aber den FLEX *nur*, wenn man konsequent alle oder einige
bestimmte Datenfelder nur noch mit der neuen Methode mehrfach besetzen
will. Ist dies nicht die Absicht, kann man bestehende Daten durchaus
einfach so lassen und HFM erst mal nur bei neuen Daten anwenden.

Die HFM-Technik im Detail
-------------------------

ALLGEMEINES

o  Die bisher möglichen Mehrfachfeld-Kennungen bleiben voll erhalten
    und funktionsfähig, d.h. bestehende Daten müssen nicht verändert
    werden. Wenn man die internen Daten aber auf UTF-8 umstellen will,
    werden z.B. die Umlaute und andere Sonderzeichen unmöglich als
    Mehrfach-Kennungen, d.h.  #31ä  etc. gehen nicht mehr.

o  Bestehende Anwendungen arbeiten mit den neuen Programmen unverändert
    weiter, es sind also keine Änderungen nötig in Parametern, FLEXen
    und Jobs, wenn man HFM nicht nutzt. Und *wenn* man es nutzt, werden
    die Änderungen sich sehr in Grenzen halten.

o  Neu hinzu kommt eine mehrstellige Mehrfachkennung aus Ziffern, die
    wie folgt aussieht und auch in Altanwendungen ohne neue Vorkehrungen
    sofort anwendbar ist, und zwar bei jeder CFG ohne Änderung (!):
            #nn.zzz   (z.B. $a.cfg, also etwa  #33.1, #33.2, .. #33.325)
      bzw.  #nnn.zzz  (z.B. $n.cfg, $u.cfg)
      bzw.  #nnnn.zzz (z.B. $p.cfg)
    mit beliebigen Ziffern z, und zwar können es auch mehr als 3 sein.
    (Max. 5 werden empfohlen; mehr sind möglich - aber sinnvoll?)
    Nur Ziffern, also auch keine Dezimalzahlen! Die erste Nichtziffer
    ist dann das erste Zeichen des Feldinhalts.
    Dafür wird der neue Terminus  "HFM-Feld"  eingeführt.

o  Die Zahlen müssen nicht lückenlos aufeinander folgen.
    Daher könnte man Nummern auch mit einer Semantik ausstatten, obzwar
    namhafte Experten aus datentheoretischer Sicht davon abraten. Es ist
    aber stets alleinige Sache der Parameter, mit den Daten etwas
    Sinnvolles anzustellen, von daher steht nichts entgegen. [Gemeint
    sind Fälle wie #31 im A-Schema, wo es Mehrfachfelder mit unter-
    schiedlicher Bedeutung (= Semantik) gibt, z.B. #31p, #31k, #31s.

o  Ältere Programme können damit nicht umgehen, sie lassen beim
    Einlesen eines derartigen Satzes nur das letzte der  #nnn.zzz-Felder
    übrig! D.h. viele Daten der neuen Art würden dann verschwinden!
    Ergo: Nach Einführung der HFM-Technik in eigene Daten keinesfalls
    mehr Programme von V34.2 oder noch ältere benutzen!

o  Zu empfehlen ist, stets mit  .1  oder einer anderen festgelegten
    Zahl zu beginnen und dann in fester Schrittweite weiterzuzählen,
    wenn man die HFM-Methode anwendet. Der Vorteil: sowohl im FLEX
    (if #nnn.1 ...) als auch in den Parametern  (#nnn.1 +X ...) kann
    man leicht feststellen, ob es HFM-Felder zu #nnn gibt.
    Die feste Schrittweite hat den Vorteil, leicht entscheiden zu
    können, ob es mehr als N Mehrfachfelder zu #nnn gibt. Z.B. mit
    Schrittweite 1 im FLEX der Test, ob es mehr als 20 sind:
    if #nnn.21 ...   und in den Parametern einfach  #nnn.21 +X e0
    Ferner kan man mit Volltextsuche nach  #nnn.101  die Erg.Menge
    aller Sätze mit mehr als 100 HFM-Feldern zu #nnn bilden.

o  Wenn dem Punkt keine Ziffer folgt, wird er als normale Mehrfach-
    kennung behandelt - wie bisher! D.h. auch wo ein Punkt schon
    in den Daten verwendet wurde, ändert sich nichts.
    AUSNAHME: Wenn dem Punkt in einem Altsatz eine Ziffer folgt! Dann
    wird das Altfeld wie ein neues behandelt: #76.2010/11  würde nicht
    mit  var #76. erkannt, sondern nur mit  var #76.2010, und das
    Ergebnis wäre "11" (d.h. das Zeichen hinter der Zahl verschwände!)

o  SEHR WICHTIG:
    Die neuen Kennungen werden im Datensatz *hinter* die bestehenden
    (mit Ziffern und Buchstaben) eingeordnet, also #nnn.1 unter #nnnz,
    und zwar nach ihrem Zahlenwert, d.h. .10 folgt auf .9

o  zzz kann eine Zahl mit führenden Nullen sein und wird dann auch
    so gespeichert. Geordnet wird zwar immer nach dem Zahlenwert, aber
    der Zugriff auf das Feld geht nur mit der eingegebenen Form, also
    mit den führenden Nullen, z.B. mit
      var #nnn.001 (falls so gespeichert)  statt   var #nnn.1
    und ebenso ist es in den Exportparametern. Jedoch:

o  Wenn ein Feld mit .001 gespeichert ist und später neu eingegeben
    wird mit  .0001 oder .1, dann kommt es an dieselbe Stelle und das
    vorher dort stehende Feld mit .001 wird dadurch ersetzt. Eine
    Abfolge  .001, .01, .1  kann es also nicht geben!
    Der Punkt ist, m.a.W., nicht als Dezimalpunkt zu verstehen.

CFG

o  Wenn in der CFG bei der betr. Felddefinition eine Angabe $M steht,
    womit die zulässigen Mehrfachkennungen eingeschränkt werden, dann
    muß auch der Punkt hinter dem $M genannt sein, wenn er bei dem Feld
    verwendbar sein soll. (Versteht sich eigentlich von selbst)
    Ohne $M ist jede Mehrfachkennung möglich, also auch der Punkt,
    aber mit  $M.  ist *nur* er möglich, keine Ziffern und Buchstaben.

EINGABE

o  Nur bei der *Eingabe* gilt:
    Hinter .zzz kann ein, muß aber kein Spatium stehen. Nur wenn der
    Inhalt des Feldes mit Ziffer beginnt, dann muß hinter .zzz ein
    Spatium stehen, das versteht sich von selbst. Ansonsten wird,
    wenn es fehlt, das Spatium automatisch ergänzt, d.h. *gespeichert*
    wird in jedem Fall *mit* Spatium, und zwar *stets* mit nur *einem*.

o  Und ganz wie bei "normalen" Feldern:
    Bei Eingabe von  #nnn.zzz  ohne Text wird das betr. Feld beseitigt;
    ebenso im FLEX mit  var ""\ins #nnn.zzz

o  Anhängen eines neuen HFM-Felds ans Ende der schon vorhandenen:
    Wenn  #nnn~ xyz  eingegeben wird (direkt oder per insert im FLEX)
    wird die letzte #nnn.zzz gesucht und auf die Zahl dann 1
    aufaddiert, um die nachfolgende HFM-Nummer zu bilden.
    Wenn keine #nnn mit . und Zahl vorkommt, wird auf die alte Weise
    ein neues #nnn-Feld ergaenzt (also z.B. #403, wenn #402 vorkommt)

o  Um mit einem Befehl gleich zwei oder mehr HFM-Felder anzuhängen,
    trennt man sie mit einem Zeilenvorschub:
      var "#nnn~ Text1" n "#nnn~ Text2" n ...
      insert
    Fuer acon gilt aber (Grund: Sicherheit gegen "code injection")
    die Schreibweise
      var "#nnn~ Text1;#nnn~ Text2;#..."
      insert
    (Das war schon lange so und klappt auch mit HFM-Feldern)

FLEX

o  Mit  var #nnn.zzz  ergibt sich stets der hinter .zzz stehende
    Inhalt, ohne das Spatium.

o  Auch  var "abc"\ins #nnn.zzz  ergibt stets  #nnn.zzz abc,
    also mit Spatium vor dem Inhalt.

o  Mit  var #nnn~  erhält man in FLEX das letzte der Mehrfachfelder
    des Feldes #nnn - wie schon bisher; mit  var _#nnn~  dasselbe incl.
    Nummer, aber ohne #. [So kann man im Falle . die letzte vorhandene
    Nummer rauskriegen]
    Mit  var #n~~  kommt das letzte aller mit Ziffer n beginnenden
    Felder. (Wohl nicht so oft sinnvoll.)

o  Mit  ins #nnn~  wird der iV-Inhalt in das nächste unbesetzte Feld
    #nnnx gesetzt. Es gibt drei mögliche Fälle:
    -- In CFG steht #nnn$Mxyz : Der nächste unbesetzte Wert aus $M
    Wenn die Angabe $M bei #nnn nicht gesetzt ist:
    -- In CFG steht  M. : Dann das nächste .-Feld, und .1, wenn es
         noch kein solches gibt, aber ein #nnn schon vorhanden ist,
         sonst einfach nur #nnn - wie schon immer
         [Bisher wird wohl niemand die Setzung  M.  gehabt haben]
    -- Beides nicht: Wenn z.B. M2 in CFG steht, dann #nnnx mit dem
         nächsten unbesetzten Wert x, mit 2 beginnend, also zuerst
         #nnn2, dann #nnn3, ...
         (Default ist aber Ma, d.h. es beginnt dann mit #nnna)
         Felder mit .zzz sind dann gleichwohl möglich, nur entstehen sie
         nicht von selbst mit  ins #nnn~ .

    Dasselbe gilt für das Programm "import", nur daß es da keinen
    Befehl "insert #nnn" gibt. Entsprechendes passiert aber, wenn man
    in den Importparametern einen Abschnitt mit
    #nnn~
    beginnt!

o  U.U. möchte man mal das erste HFM-Feld von #nnn haben. Aber mit
    "var #nnn."  kriegt man das erste aller #nnn-Felder, nicht das erste
    mit einem Punkt. Dafür gibt es keinen einfachen Befehl. Es sei denn
    man hat stets  .1  als erstes HFM-Feld, was aber nicht zwingend ist.
    Die erste Nummer bei #77 findet man ersatzweise mit diesem Rezept:
      var kr
      var (b"77." e" ")
      ins $n1
      var "_#77." $n1
      var
    In der iV steht dann z.B. 77.8 text, wenn .8 das erste HFM-Feld ist.

o  Der FLEX-Befehl  var kr  bzw.  var kn  wirft auch die .-Felder
    alle mit aus. [Was auch sonst?]

o  In FLEX geht AUCH:  if #nnn.zzz ...
    Dabei ergibt sich die erwartete Reaktion.
    Man kann also durchaus schreiben
    if not #77.123 mes #77.123 ist nicht besetzt
    und die Meldung kommt dann und nur dann, wenn #77.123 fehlt.

o  Achtung: mit  if #nnn.  kann man nur testen, ob es *irgendein* Feld
    #nnn  gibt, aber nicht, ob es welche mit einem Punkt gibt! Das geht
    nur so:  var _#nnn~\if ="nnn." ...
    Denn damit läßt man sich das letzte der #nnn-Felder incl. Nummer
    geben und prüft, ob es mit "nnn." beginnt (Denn die .-Felder sind
    immer am Ende)

EXPORTPARAMETER (incl. INDEX)

o  In Exportparametern:  #nnn~  ergibt das letzte der Felder mit #nnn
    Wenn es zu #nnn Felder mit .zzz gibt, ist #nnn~  das letzte solche
    Feld - dahinter können nämlich keine anderen mehr kommen.
    Spezialfall:
    Will man gezielt das letzte Feld NUR dann, wenn es eins mit . ist,
    dann  #nnn.00 (#nnn.00 kann nicht vorkommen, nur #nnn.0)
    Das liefert den Textinhalt des Feldes! Will man auch die Nummer,
    dann
    #bks=0
    #nnn.00
    #bks=k    (k = Wert  k  aus der CFG bzw. Wert von ks= in den Param.)

o  In Parameterdateien wird unverändert  ak=nnn."xyz"+B  geschrieben,
    um alle Einzelfelder abzuarbeiten, einschl. der neuen mit .zzz

o  Ein HFM-Feld kann ganz normal exportiert werden:
    #nnn.zzz ...(Manip.Befehle)
    Dies wird nur in begründeten Einzelfällen nötig sein, weil es sich
    ihrer Natur nach dabei eben um Mehrfachfelder handelt, die man im
    Normalfall *alle* exportieren will, nicht einzeln, und zwar mit der
    üblichen Methode:

o  Mit  #nnn. ++ ...  erreicht man, wie bekannt, eine schleifenförmige
    Abarbeitung aller Mehrfachfelder von #nnn, incl. der HFM-Felder.

o  Mit ## erhält man bei der Einstellung ks=4 (bzw. dem Wert k aus der
    CFG, also z.B. 5, wenn man k5 dort hat) die Liste der Feldinhalte
    ohne die Feldnummern; die ausgegebenen Inhalte der HFM-Felder
    beginnen also in dem Fall nicht an der Position ks, denn der
    Textbeginn richtet sich ja dann nach der Länge der Zahl .zzz
    Mit jedem anderen Wert von ks werden aber auch die HFM-Felder ab
    der betr. Position ausgegeben - wobei wohl nur ks=0 und ks=1
    wirklich mal sinnvoll sein können, also Ausgabe mit Kategorienummer
    incl. bzw. ohne das '#' am Anfang.

ANSONSTEN

o  Für den Hintergrundspeicher gilt die Neuerung nicht!
    Dort entstehen drei Mehrfachfelder mit . / 0, die sich zyklisch
    verschieben. (Das entspricht bisheriger Funktionsweise und ist
    vermutlich weder besonders nützlich noch überhaupt bekannt.)

o  Für die #u-Variablen gibt es keine Änderung, d.h. man kann nicht
    #uxy.1 und #uxy.123 usw. verwenden. Das macht wohl kaum etwas
    denn es sind ja nur temporäre Variablen, und in FLEXen verwendet
    man eh lieber $- oder &-Variablen, die anderen Gesetzen folgen.

ACHTUNG!
Hat man einmal das neue Verfahren eingeführt und gibt es Datensätze
mit HFM-Feldern, werden damit ältere Programme nicht korrekt arbeiten.
Und zwar, wenn man z.B. mit einem älteren SRCH.EXE eine Ergebnismenge
macht, bleibt nur das letzte von mehreren #nnn.zzz dann übrig.

Umwandlung von Altdaten
-----------------------

WICHTIG: Standard-Anwender des Formate $a.cfg brauchen nichts zu tun,
sondern können das nachfolgende ignorieren!

Wer Mehrfachfelder in großer Zahl hat und eine bessere Methode zu
deren Handhabung wünscht, kann mit V34.3 leicht seine problematischen
Daten in die neue HFM-Form bringen.

Wichtig, wenn man auf interne UTF-8-Codierung umsteigen will:
Unverzichtbar wird die HFM-Umwandlung künftig sein, wenn man z.B.
Mehrfachfelder mit Umlauten und anderen Sonderzeichen an der
Mehrfachposition hat, also z.B.  #31ä  oder  #40é, denn mit denen
gibt's unter UTF-8 Ärger. [Das war mit ein Grund, die HFM-Methode
zu entwickeln.]

Umwandlung empfiehlt sich also NUR, wenn es wirklich sein muß und man
sich im Klaren ist über das Warum und Wozu und den Nutzen.
(Das ist nicht als indirekte  Warnung vor HFM zu verstehen, sondern
als Hinweis an Standard-Anwender, denen man solche Dinge nach unserer
Erfahrung durchaus nicht oft und nicht klar genug sagen kann, sonst
bleibt ein Rest von Verunsicherung.)

Wir haben einen FLEX geschrieben namens  hfmu.flx, der vorhandene
Daten in variabler Weise umwandeln kann.
Diesen soll man aber keinesfalls unbesehen anwenden!
Darin sind folgende Modifikationen möglich (alles intern dokumentiert):

   1. *** Fuer Gesamtdurchlauf: die mit *** markierten Zeilen aktivieren
      Sonst wird nur der aktuelle Satz umgewandelt. Das ist sinnvoll, um
      erst einmal die Sache mit verschiedenen Datensätzen zu testen.

   2. Wahlweise kann man die umgewandelten Sätze gleich wieder speichern
      lassen oder aber in eine Grunddatei exportieren, dies dann wahlweise
      in unveränderter Codierung oder aber gleich in UTF-8 umcodiert.

   3. ACHTUNG: Wenn bestimmte Mehrfachfelder eine Semantik haben!
            Dann diese unter  :except  eintragen, s.u.
            ODER nur bestimmte Felder wandeln lassen.
      M.a.W.: Es ist nicht nötig, *alle* Mehrfachfelder in die neue
      Form zu wandeln; die gewohnte Semantik kann beibehalten werden.

   4. Falls 3- bzw. 4stelliges Schema: (t3 bzw. t4 in der CFG)
      dann im gesamten FLEX folgendes tun:
            (0,3) ersetzen durch (0,4) bzw. (0,5)
            (4,0) ersetzen durch (5,0) bzw. (6,0)
            (3,1) ersetzen durch (4,1) bzw. (5,1)

   5. Wenn schon HFM-Felder vorhanden sind, klappt's auch!
      (Nur die Nummern bleiben u.U. nicht erhalten,
       und aus  #nnn.1 TEXT  wird  #nnn  TEXT, falls #nnn unbesetzt)
      Wenn nicht erwuenscht, dann unter :except ausblenden lassen

ACHTUNG: Wichtige Vorbereitung!

Oben unter "CFG" wurde darauf hingewiesen:
    "Wenn in der CFG bei der betr. Felddefinition eine Angabe $M steht,
     ... dann muß auch der Punkt hinter dem $M genannt sein, wenn er
     bei dem Feld verwendbar sein soll.
Siehe dazu Punkt 3. oben: Man muß zuerst prüfen, ob man Felder mit $M
in der CFG hat (statt $ steht evtl. der Code 31 (Dreieck)).
Entweder das Feld dann unter :except eintragen,
Oder hinter $M den Punkt einfügen, wenn sie umgewandelt werden dürfen,
      d.h. die Mehrfachfelder keine Sonderbedeutung haben.

Man startet die Umwandlung mit  X hfmu
nachdem man die geeigneten Modifikationen gemacht hat!

Aber bleiben Sie entspannt. Zunächst einmal kann man wie folgt
testen, ohne daß schon irgendwas passiert.

Voraussetzung: man hat das aktuelle, schon HFM-fähige a99.
Hier ist es: (Datum 1.7., 10:19)
   http://www.allegro-c.de/aktuelle-version/a99hfm.zip
Mit den vorhandenen Daten funktioniert das darin befindliche
a99hfm.exe völlig unverändert.
[In V34.3 wird es wieder a99.exe heißen]

Und so holt man sich den FLEX zum Ausprobieren:

   X getfile hfmu.flx

Wenn man ohne Änderungen  X hfmu  gibt, wird nur der aktuelle
Satz gewandelt und gezeigt, aber nicht gespeichert.
Damit kann man sich also zuerst einfach mal anschauen, was
der FLEX aus den eigenen Daten macht. In der Anzeige und mit
F7 sieht man auch sofort, ob alles noch klappt oder was eben
nicht mehr klappt. Und dann evtl. Modifikationen machen, s.o.

Dann sucht man sich mal interessante Datensätze und gibt  X hfmu
Mit Alt+w schaltet man - wie üblich - zwischen dem Original
und dem veränderten Satz vor und zurück, um sofort die Änderungen genau
zu sehen.
Vor dem nächsten Beispiel am besten mit Alt+w das Original wieder
einstellen, damit die veränderte Fassung noch nicht gespeichert wird.

Soll, nach erfolgreichen Tests, die gesamte Datenbank verarbeitet
werden, dann in  hfmu.flx  die mit *** markierten Zeilen aktivieren,
danach ein letztes mal:  X hfmu  und alles wird gewandelt. Das kann
aber dauern!

Natürlich kann man auch den  put-Befehl  deaktiviert lassen, dann
nach dem Durchlauf sich die geänderten Sätze alle anschauen und
mit Alt+w vergleichen mit dem Original. Wenn unzufrieden:

   x erase off

und nichts wird gespeichert.
Man wird tunlichst zuerst gründlich untersuchen, ob die geänderten
Sätze genau dieselben Schlüssel produzieren, bevor man einen
Gesamtdurchlauf mit aktiviertem put-Befehl macht.

ODER: "exp" statt "put nehmen und ganz oben die Befehle
exp p i-1
exp f neudat.alg

Dann wird in der Datenbank gar nichts verändert, sondern die umgewan-
delten Sätze in die Datei  neudat.alg  geschrieben. Genauer gesagt:
alle Sätze, ub verändert oder nicht. Und "neudat.alg" kann man in ein
anderes Verzeichnis tun, doer indexieren und sich dann das gesamte
Produkt anschauen.
Tip: Wenn neben der HFM-Wandlung auch noch andere Žnderungen zu
machen sind, z.B. Zeichencodierungen (Unterfeld-Steuercode, Nicht-
sortierzeichen, ...), so kann man diese mit in die  i-1.apr  einbauen
um das im selben Durchlauf zu erledigen. In den Indexparametern fr
die anschlieáende Neuindexierung sind diese Sachen natrlich auch
zu bercksichtigen!

Wir haben die Umwandlung schon getestet mit der Spezialkonfiguration
eines Anwenders, der sehr viele Mehrfachfelder hat, mit einem
3stelligen Schema. Der FLEX schafft gut 100 Sätze je Sekunde,
wenn auch noch ohne Speicherung. Die ist jedoch auch nicht sehr
zeitkritisch, wenn keine Schlüsseländerungen resultieren!