[Allegro] nachgefragt: "2run nach qrix - bedeutung?"

[Thomas Berger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lieber Herr Eversberg, liebe Liste,

>> des öfteren, nicht immer:
>> kommt nach einem qrix-durchlauf:
>>
>> 2run (in grün)
>>
> Nicht ganz. "2nd run" heißt es.
> 
> Da hat qrix.exe nochmal index.exe gestartet, zu prüfen, ob es noch
> auflösbare Zeilen gibt, die mit _ beginnen (oder anderem Steuerzeichen,
> das mit i5 in den Indexparametern definiert ist).
> Das kann geschehen, wenn beim eigentlichen zweiten Durchlauf von
> index.exe (mit - at 2) nicht alle Auflösungen möglich sind, weil die
> Ersetzungsschlüssel nicht, wie es soll, im ersten Durchlauf alle
> gebildet werden, sondern einige erst im zweiten. Daher wird am
> Ende noch  index -fa ...  gestartet und führt dann die restlichen
> Ersetzungen durch, damit man sich nicht ärgert, sondern allenfalls
> wundert.
> 
> Zwecks Verwirrungsverhütung sollten wir wohl die Sache in
> "3rd run" umbenennen...

oder abschaffen:

Die Sache hatte ihre Berechtigung, bevor die zweistufige Indexierung
geschaffen bzw. ermoeglicht wurde. Jetzt ist sie eigentlich
ueberfluessig. Uneigentlich ist es allerdings so, dass auch die
Standard-cat.api auf dieses Feature baut, weil (wenn ich mich recht
entsinne, die unseligen mnemnonischen Zeitschriftenkuerzel aus #8na
nicht waehrend der ersten Indexierungsphase ins Register gesetzt werden,
sondern erst waehrend der zweiten. Wer in #70 mit diesen Kuerzeln
verknuepft, ist wegen dieser Unzulaenglichkeit in den Parametern
auch heute noch auf den 2nd run angewiesen.

Der 2nd run untersucht alle "_"-Eintragungen in allen Registern
und versucht sie aufzuloesen. Ich habe neulich eine Datenbank mit
der erweiterten v14-Verknuepfungsmethodik von v23 aufgesetzt (vgl.
vb163 oder 164), dabei stehen ja die Ersetzungsschluessel mit "_"
im einschlaegigen Register. Der Effekt ist, dass nach der qrix-Phase
die Indexierung eine deutlich merkbare Zeit im 2nd run verharrt,
(gluecklicherweise aber keine Ersetzungen ausfuehrt, denn sonst
waeren die Ersetzungsschluessel ja gekillt worden), und das bei
einer 5stelligen Zahl von Stammsaetzen. Ich habe aber auch Datenbanken
mit 7stelliger Zahl von Stammsaetzen, die ich mittelfristig auf
diese Art der Verknuepfung umstellen moechte, fuerchte aber einen
noop-2nd run im Stundenbereich...

viele Gruesse
Thomas Berger

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGrk4khKFJT0F1FsoRAr4yAJ4in15jNCp01SsgKIaIMBW3A93g4QCfY8i7
0VZJMhDXZ1lyq1KkNSHgHoA=
=ZqWM
-----END PGP SIGNATURE-----