[Allegro] acon: if Del ... nach fetch record

[Thomas Berger]

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

Lieber Herr Eversberg,


> Programm acon hat zu jedem Zeitpunkt genau einen aktuellen Satz im
> Arbeitsspeicher (der kann leer sein). Mit "fetch" wird ganz allgemein
> aus einer Datei gelesen, das kann irgendeine sein, die mit allegro
> nichts zu tun hat und die man vorher mit "open name" geöffnet hat.
> Was gelesen wird, landet in der iV.

> Ist es eine allegro-Datei (.ALG, .ADT, .LOG, .ALD), wird mit dem
> Spezialbefehl "fetch rec" der Satz in definierter Weise eingelesen,
> aber eben auch in die iV, nirgends sonst, und die Variable iR wird
> mit seiner Satznummer belegt - falls es .LOG oder .ALD ist. Die
> Bedingung "Deleted" wird gesetzt, falls es ein als gelöscht markierter
> Satz einer .ALD oder .LOG ist, iR ist dann negativ.
> Das ist alles.

> Denkbar ist also, und man sollte es nicht ausschließen, daß das
> Einlesen den aktuellen Satz nicht stören soll, sondern daß man es
> nebenbei, aus welchem Grund auch immer, veranstaltet.

Knackpunkt ist das Verhalten bezueglich iR. So wie Sie es schildern,
ist also nach fetch record ein Zustand erreicht, wo iR nicht mehr
die Satznummre des aktuellen Satzes enthaelt, sondern eine andere
Nummer. Die "wahre" Satznummer gibt es hingegen unzugaenglich auch,
sie wird etwa in Downloads als #nr 0 offenbart.

Vor allem letzteres ist ein Problem, weil unzaehlige Legacy-Exporte
darauf eingestellt sind, die interne Satznummer (.ald) bzw. die fortlaufende
Position in der Eingangsdatei (.alg) als #nr zu exportieren
und man srch.job nicht dadurch aufblaehen moechte, den Satz ausser
sequentiell aus der .ald-Datei auch noch parallel aus der Datenbank zu
laden, damit die sichtbare Satznummer iR und die "wahre" Satznummer
#nr kohaerent sind.



> Welcher Dateityp es nun gerade ist, dazu bedarf's keiner weiteren
> cstring-Sondervariablen, das kann man sich in $Dateityp merken oder,

woher kommt die Information, die ich mir merken kann?


> wenn man faul ist, in $t, falls man sich das überhaupt merken muß
> und nicht aufgrund der Umstände gar kein Zweifel aufkommen kann,
> was der Normalfall sein dürfte.

Die Umstaende sind, dass eine Datei geoeffnet wird und acon dann
eine Entscheidung trifft, die zunaechst einmal seine internen
Ablaeufe angehen: Ist nur ^A ein erlaubter Satzanfang oder auch
^8 und ^9 bzw. sind nach dem Satzanfang vier Binaerbytes, ist der
Feldtrenner ^@ oder ^J "#" etc.

Acon macht das, damit der Anwender sich nicht kuemmern muss, aber
spaetestens dann, wenn es um die interne Satznummer geht, gibt
es Unterschiede: Ist die Zahl eine interne Satznummer oder ist
sie Schmutz? Und die eigene Analyse bzw. "aufgrund der Umstaende
kein Zweifel" sind hier kontraproduktiv: Entweder ich kann acon
zwingen, seine Algorithmen entsprechend meiner Vorgabe anzupassen
oder acon muss mir seine Entscheidung mitteilen, zwei unabhaengige
Entscheidungen wie derzeit bergen das Risiko zur Inkohaerenz



> Daß "fetch" momentan in acon keine andere Aktion machen kann als
> "fetch rec", das tut der Sache keinen Abbruch, es wird bei Bedarf
> auf den Funktionsumfang von a99 erweitert, mit dem es dann
> natürlich kompatibel sein sollte. Momentan ist es das nicht.
> In a99 muß man folgende Sequenz nehmen, wenn man eine .ALD liest und
> Satznummer und Satzstatus haben will:
> 
> fet b     // liefert 9 in iV, wenn gelöscht, sonst 1 oder 8 (gesperrt)
> fet b4    // liefert interne Satznr in iV
> z=        // kopiert sie in den internen Zähler
> fet rec
> Und hiermit steht dann der Satz mit Zeilentrennern in der iV, nicht mit
> statt dessen ;# (Code 00 wird in a99 durch 10 35 ersetzt)

Das ist mir viel sympatischer, v.a. letzteres (vgl. meinen Hinweis, dass
"fetch record" bei acon in der iV etwas ablegt, das in entscheidenden
Details von der Form bei "var kn" abweicht.


> Das ist natürlich noch unbefriedigend, wird aber z.B. in ftr.flx
> verwendet. Irgendwas muß da noch geschehen.

"fetch rec" fuer acon ist ja erst im Januar/Februar eingefuehrt worden,
weil "read" zu pauschal ist, um gewisse Update-Funktionalitaeten zu
realisieren. Fuer (elaborierte) Exporte halte ich persoenlich "fetch rec"
auch fuer guenstiger, weil ich "ins" fuer eine kostspielige Operation
halte und im Zusammenhang mit gewissen Suchbegriffen die kleinschrittige
Vorgehensweise daher mehr Moeglichkeiten zum Tuning bietet.

D.h. *jetzt* waere eine guenstige Gelegenheit, das Verhalten von acon
an dieser Stelle dem von a99 anzugleichen, denn das von acon ist so
neu, dass es noch nicht an besonders vielen Stellen eingebaut sein kann
und das von a99 scheint mir sauberer.

viele Gruesse
Thomas Berger

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iJwEAQECAAYFAkwYeHcACgkQYhMlmJ6W47N/kQP/YFMQzFZpJuOIJJZg6EzoGkgg
LeO1DvEyGoXOjkXx34+aCZjAFolZMgjWZ+YPae2tk9XVBEB7L8SrPguTqChfykx9
VB62WjpsmtTbS0uixekpfwozNMbxru3Eaq1PSu6xL08FDJlkqPPxncpUqtl5I4dm
Don75Igh4bAROnQT0/4=
=vp1F
-----END PGP SIGNATURE-----