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

[Klaus Lehmann]

guten abend herr berger ,
ehe mistverständnisse auftauchen und ich den "3. teil" präsentiere,
der für mich was ganz wichtiges "beweist", erst hier meine "anmerks"
zu ihrer email:

> 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!

neiiin!
da ist kein doppeltes "LEER". das ist der blöde editor von
"TheBat" (meinem moldawischen mailprogramm ;-)
er war bis vor kurzem auf BLOCKSATZ gestellt.
ich habe es ENDLICH geschafft, dieses abzustellen.
sorry.
nirgendswo sind LEER's!



> 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.
ja. dürfte so 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.]

ups. vergessen zu notieren:
update.job (aus letzter version aus BS)
header:
// update.job : Emulation der Funktionen von UPDATE.EXE mit acon
// $HeadURL: https://svn.allegro-c.de/svn/download/prog/update.job $
// Originalversion von Th. Berger 2011, modif. B. Eversberg 2012-01
// beruht auf $Id: update.job 24123 2011-12-08 23:13:27Z ThB $
// $HeadURL Orig.: https://svn.extra.gymel.com/repos/allegro/acxt/aconjob/trunk/
update.job $
// Begriffe: "Aufruf" statt "Kommandozeile"
//           "Option" statt "Schalter" und "Kommandozeilenparameter"
//           "Flags" sind Var., die nur durch Existenz oder Fehlen wirken
// Kommentar ERWEITERUNG: Hier kann man eigene Dinge einbauen
// -T1: einige Meldungen (war $VERBOSE)
//$TEST1
// -T2: viele Meldungen (war $CHECK)
//$TEST2
// Version dieses Jobs (1=Entw.Abt. Urjob, 2=Berger, 3=Ueberarbeitung Entw.Abt.)
$VERSION=3
// ab welcher acon-Version klappt's? (Pruefg. in optsget.inc)
$OP.reqV=32.0



> 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.
ich versuchs. aber erstmal "teil3", gleich....

> 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.
   ~~~~~~~~~ ja. ich denke, es wird il=244 sein
LETZTendes wird mir die hintere grenze ziemlich WURSCHT sein.
ich bin SEHR zufrieden, wenn es einen "eineindeutigen" PS gibt, der in
den grenzen [vor 1945?] vor dem offiziellen il-Wert zuverlässig
arbeitet.
weil ich davon ausgehe [ich erwähnte es "wohl" schon:] der PS wird
genug in den ersten 240-245 zeichen zu tun haben, um seine
eineindeutigkeit zu demonstrieren.

aber lassen sie uns teil3 geniessen....
gleich....


gruß k.l.


> viele Gruesse
> Thomas Berger


> _______________________________________________
> Allegro mailing list
> Allegro at biblio.tu-bs.de
> http://sunny5.biblio.etc.tu-bs.de/mailman/listinfo/allegro



-- 
Mit freundlichen Grüßen,
Ihr Klaus Lehmann
http://allegronet.de * eMail: allegronet at t-online.de * phone: 03528-452 807(fax 809) * mobil: 0171-953 7843
allegronet.de * Klaus Lehmann * D-01454 Radeberg * Bahnhofstr. 1
zuständiges Finanzamt: FA Hoyerswerda; zuständige Kammer: IHK Dresden;
zuständige Aufsichtsbehörde: Gewerbeamt Radeberg; USt-IdNr: DE247550760
* Software für zufriedene Bibliothekare: 1000x bewaehrt und ergiebig
* Bereits 4x allegro-utf8. Buchen Sie die allegro-Roadshow. Yes we can!
* Internetkataloge & WebHosting für Allegro-C & Web 2.0 mit VuFind
* 2011: Sponsor der Peter-Sodann-Bibliothek (Staucha)
* 2012: mit allegro-utf8 V3 und allegro-vufind auf der IFLA in Helsinki
* 2013: Bolero 64bit. Fußige Noten aufgeblättert (=Die Fußnotendoku)
* 2014: allegro-zdb: endlich. Die Wiedervereinigung! + eBooks
* 2015: allegro-vufind. Endlich! Noch moderner! Web2 auch für Ihren Katalog?





Am Dienstag, 1. September 2015 um 22:40 schrieben Sie:
> 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


> _______________________________________________
> Allegro mailing list
> Allegro at biblio.tu-bs.de
> http://sunny5.biblio.etc.tu-bs.de/mailman/listinfo/allegro