[Allegro] Vb.260 Vorabdruck: HFM
Bernhard Eversberg
ev at biblio.tu-bs.de
Mo Jul 7 15:13:58 CEST 2014
VORABDRUCK!
Korrekturhinweise können bis morgen, 8.7., 10:00 berücksictigt werden
Verlautbarung 260 der Entw.Abt. 2014-07-07
-------------------------------
HFM (Hochfrequente Mehrfachfelder)
==================================
[Erstmals vorgestellt am 23.6., nach Diskussion im Forum 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 die meisten Sonderzeichen waren möglich. Für beispielsweise ein
Feld #64 konnte man haben: #641, #642, ... , #64A, #64a, #64ä usw.
Damit waren maximal ca. 220 Belegungen zu erreichen.
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. Aber mehr zu den Einzelheiten
weiter unten.
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 tun 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 mit
einzelnen Feldern für Anzeige, Index oder Exporte umgegangen wird.
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.
Die HFM-Technik im Detail
-------------------------
o Die bisher möglichen Mehrfachfeld-Kennungen bleiben voll erhalten
und funktionsfähig, d.h. bestehende Daten müssen nicht verändert
werden.
o Bestehende Anwendungen arbeiten mit den neuen Programmen unverändert
weiter, es sind also keine Änderungen nötig in Parametern, FLEXen
und Jobs.
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.
o 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 bei var ""\ins #nnn.zzz
o Anfügen 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 anzufügen,
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)
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 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.
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 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 kann man, wie bisher, ak=nnn."xyz"+B schreiben,
um alle Einzelfelder abzuarbeiten, einschl. derer 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 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.
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~(e" ")\if %.% ...
Denn damit läßt man sich die Nummer der letzten #nnn geben und
prüft, ob darin ein . steckt. (Denn die .-Felder sind immer am Ende)
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
-----------------------
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.
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. 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.
3. 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)
4. 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
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.
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!
Mehr Informationen über die Mailingliste Allegro