[Allegro] neues acon und a99.exe! bei extremsituationen! 2.teil

[Thomas Berger]

Am 01.09.2015 um 20:16 schrieb Klaus Lehmann:
> so, teil 2
> 
>> folgendes ist vorbereitet:
>> =========================
>> wir haben eine ald, die hat erstmal 6 datensätze.
> 
>> der PS ist so in der api gebildet:
>> i0=72          Laenge der Kurzanzeige
>> i1=0
>> i2=0
>> i3=0
>> ic=1           nur wenn Umcodierung der Eingabe gewuenscht
>> il=246         Schluessellaenge (frueher 72)
>> ii=6           grüße der alds 6x16GB
>> ia=0       es wird nach der exakten sequenz gesucht
> 
>>    und weiter mit:
>>   Primaerschluessel:
>> ak=zz+@
>>     und:
>> #-@
>> #10  y0 e245 F032 p"|9"        das letzte zeichen darf kein LEER sein!

sehr schoen: Das doppelte Leerzeichen vor dem y0 bringt
den Inhalt so raus, wie er ist, ohne durch Ihr e245
abgelenkt zu werden. Wir sehen also den Effekt des il=246

Ob's nach Register 9 oder nach Register 1 geht, sollte fuer
den Test hoffentlich egal sein.



>>                                es wird vernichtet!
>> #+#
> 
>> die sechs datensätze:
>> ====================
>> 1. #10 1234567890Hier vorne am Anfang ist der Zähler auf 1. So
>> erfüllen wir Herrn Berger's Auftrag, doch endlich in den Index zu
>> schauen. Idee: Wir schreiben eine 3stellige Zahl vor das nächste X,
>> Beispiel 240X. Das X steht auf 240! 24X1234567 auf 245X
> 

unterscheiden sich erst weit jenseits der Grenze.


>> ergeben ein bild bei der darstellung des Index' in a99, wenn man auf
>> F7 drückt:
> 
>> |11234567890Hier vorne am Anfang ist der Zähler auf 1. So erfüllen
>> wir Herrn Berger's Auftrag, doch endlich in den Index zu schauen.
>> Idee: Wir schreiben eine 3stellige Zahl vor das nächste X, Beispiel
>> 245X. Das X steht auf 245! 24X1234567 auf 245X6

sehr schoen: 246 Zeichen und "|1" davor. So hatten wir den Effekt von
il bislang auch verstanden.


>> das war der 1. teil
>> ===================
> 
>> im 2. teil versuche in in die 6 datensätze mit update-job
>> einzudringen....
> 
> so, ich dringe ein!
> mit:
> set no=200
> set -P=x:\allegro
> x:\allegro\acon.exe -jx:\allegro\update.job -kaimd -fm41 -dx:\imd\imd -ux:\test.alg -n%no% -L -F0/0 -xUPROtest
> 
> 
> \imd besteht aus den o.g. 6 sätzen.
> 
> test.alg hat DAS zum inhalt:
> 
10 1234567890Hier vorne am Anfang ist der Zähler auf 1. So erfüllen wir Herrn Berger's Auftrag, doch endlich in den Index zu schauen. Idee: Wir schreiben eine 3stellige Zahl vor das nächste X, Beispiel 245X. Das X steht auf 245! 24X1234567 auf 245X 15 ~01234
...
> jeder satz ist verschienden lang.
> in #15 hat er auch verschiedenlange inhalte.
> 
> 
> 
> was passiert? Hier die UPRO! DAS ist spannend:
> [19:49:59] ac-w v35.8: Verarbeitung beginnt, Datenbank x:\imd\imd
> [19:49:59] Datei x:\test.alg wird verarbeitet
> 
> [19:49:59] 1. Satz eingelesen :
> Gesucht: >|9 1234567890Hier vorne am Anfang ist der Zähler auf 1. So erfüllen wir Herrn Berger's Auftrag, doch endlich in den Index zu schauen. Idee: Wir schreiben eine 3stellige Zahl vor das nächste X, Beispiel 245X. Das X steht auf 245! 24X1234567 auf 245=?<
> Gesucht: >|9 1234567890Hier vorne am Anfang ist der Zähler auf 1. So erfüllen wir Herrn Berger's Auftrag, doch endlich in den Index zu schauen. Idee: Wir schreiben eine 3stellige Zahl vor das nächste X, Beispiel 245X. Das X steht auf 245! 24X1234567 auf 245<
> Status: Nichts gefunden 0
> [19:49:59] Neusatz gespeichert in Datei 200 (Laenge 1294)

> ENDE
> 6 Saetze verarbeitet
> 0 Saetze ersetzt
> 5 Saetze gemischt
> 0 Saetze ignoriert
> 0 Saetze entfernt
> 1 Saetze neu
> 
> 
> hm.
> 1. spannend finde ich, daß der PS jedesmal an der selben stelle
> aufhört! bei "auf 245". also 1 stelle VOR dem x. (ist nicht schlimm!)
> 
> 2. hm. eigentlich ist bei update JEDER datensatz gleichlang.
> nein! mit dem 1. satz kann er nix anfangen. speist in in die -n200 ab!
> alle anderen landen im satz 7. WARUM?

weil die Unterschiede erst ab der Position liegen, an der abgeschnitten
wird. Ihr Test zeigt aber schoen, dass die eigentliche Indexierung
anders abschneidet als "var p".

Ich haette erwartet, dass es 6 Neusaetze gibt, weil "var p"
eine Stelle vorher abschneidet, gibt es keinen Treffer, beim
Speichern des vermeintlichen Neusatzes wird dann ein laengerer
Schluessel in den Index gesetzt, beim naechsten Satz wieder
nichts gefunden etc. Das scheint so nicht zu stimmen.
[Es hat natuerlich auch mit der jeweiligen Version von update.job
zu tun, die aktuelleren nehmen ja nicht den nackten Wert von
"var p", sondern schneiden selber bei 246 Zeichen ab, das
entspricht allerdings, da das Praefix dabei ist, der Situation
il=244.]

Man koennte nun einfach in den Index schauen, wie die Schluessel
tatsaechlich aussehen, die da als 6fach-Treffer fuer Satz eins
bis 6 und als Einfach-Treffer fuer Satz 7 vorliegen: Die werden
sich am Ende irgendwo unterscheiden: Alt-i geben, dann #

Der bei 244 abgeschnittene Wert von "var p" findet aber ab dem
zweiten Update-Satz ein Pendant, d.h. der Schluessel steht in
dieser staerker gekuerzten Form auch im Index, wo er beim Speichern
hneingekommen ist. D.h. das "var p" und das folgende (0,246)
haben den "echten" Schluessel nicht weiter gekappt.

Das laesst zwei Erklaerungen zu:
a) acon und a99 interpretieren den Parameter il auf unterschiedliche
Weise (fuer acon ist es effektiv 2 kleiner)

Oder: b) Dasselbe wie vorher, jedoch nur fuer Werte von il >= 245.

Wenn Sie denselben Test einmal fuer il=240 durchfuehren, wissen
wir's.

b) waere ziemlich uebel, denn wenn acon und die anderen Programme
generell unterschiedliche Interpretationen von il haben, bedeutet
das eine mysterioese Schluesselverdopplung durch Speichern bei
allen Schluesseln, die dem Limit bis auf zwei Nahe kommen. In
allen Datenbanken.

a) waere nicht ganz so uebel, man duerfte dann eben nie ueber il=244
(oder 245?) hinausgehen.


viele Gruesse
Thomas Berger