[Allegro] acon bringt fehler: "Befehl nicht korrekt geformt"

Fr Nov 14 08:52:41 CET 2014

Guten Tag Herr Eversberg,
danke für Ihre Nachricht.
Am Mittwoch, 12. November 2014 um 09:58 schrieben Sie.
Ihre Nachricht finden Sie am Ende dieser eMail.

erstmal: vielen dank dafür, daß sie den fehler gefunden haben!
meine skriptläufe laufen ohne fehler ab! danke!

nachbetrachtungen ....:

> Am 07.11.2014 10:58, schrieb Klaus Lehmann:
>> Die Fehlermeldung "Befehl nicht korrekt geformt" kommt bei einer acon-aufgabe mit update.job
>> Der Bildschirm sieht so aus:
>> 296. Satz  :    >|9zdb82769-1<N:<E130> kein Ergebnis bei: |9 "zdb82769-1=?"
>> Befehl nicht korrekt geformt
>> EXCEPTION-Error (memory-access) in program "acon.exe" !!Drücken Sie eine beliebi
>> ge Taste . . .
> Vorweg:
> Standardanwender sind nicht betroffen.
> Bereitgestellt:
>    ftp://134.169.20.101/a99.zip
>    ftp://134.169.20.101/acon.zip

> Es war ein Folgefehler. Der eigentliche Grund ist: Es entstehen bei
> einem Satz mehr als 1000 Indexeinträge.
....
> und mit der 0 dann überschrieben wird. In diesem Fall ging's dann
> wirklich schief. Die beobachteten Meldungen weisen auf den eigentlichen
> Tatbestand nicht hin, das ist aber typisch in solchen Fällen.

             ~~~~~~~~~  ja. leider. das machte es ja so schwierig für 
             mich, überhaut zu erkennen, daß da IN der gegend ein 
             fehler vorgelegen hat. der obige satz ist an 296.stelle, 
             der satz, der der böse war, ist 12 sätze zuvor: an 
             284.stelle geht man nun, wie herr th.fischer gerne mit 
             dem notepad++ da ran, oder mit anderen 
             betrachtungswerkzeugen; was mag man sehen: einen nicht 
             gerade SEHR großen datensatz, der ca 1 1/2 dina4-seiten 
             groß ist. der 284.satz (bundesanzeiger) ist also "nur" 
             8800bytes schwer.
             ich rufe und allen noch mal grenzen.html ins gedächtnis:
             maximalefeldlänge: 10.000bytes. wird hier lange NICHT 
             erreicht. "D.h. die Grenze für einen einzelnen Datensatz 
             liegt bei ca. 20000 Byte". unser datensatz: ein winzling!
             also alles im grünen bereich. man konnte also NICHT mit 
             einem dateibetrachter das problem erkennen.

es geht mir bei dem "plädoyer" um die geeigneten werkzeuge. 
ich fing ja an mit der aufzählung (s.a. 7.11.). 
herr eversberg ergänzte am 10.11. um die von mir einfach "vergessenen"(sorry). 
h. berger empfahl sinngemäß, nicht wörtlich: "schau dir die 50 
datensätze ZUVOR und DANACH um die fehlermeldung an!" (sinngemäß! ;-)
all das hatte aber NIX gebracht. niente.

also: WIE gehen wir ran, um ein acon-fehler zu analysieren?
(oder anderes allegro-programm, wie index,qrix
[bei srch und update haben wir bessere möglichkeiten?])

DAS ist DAS problem.             

> Es stellte sich bei den konkreten Daten heraus, daß der Titel
> "Bundesanzeiger" schuld war (ZDB 33414-5). Der will 1011 Schlüssel
> generiert haben. 

ich frage mal: WER erstellt denn die schlüssel?
sie haben acon und a99.exe erneuert....
a99 kann's nicht sein. es war nicht im spiel dabei!

macht acon das? vermutlich.

aber was ist dann mit dem klassischen gespann index.exe/qrix.exe?
ich kann mir vorstellen, es gibt scriptläufe, da wird mit index.exe 
auch so ein material in eine datenbank reingespielt. so hätte ich es 
gemacht, wenn ich keine funktion mit -fm?? benötigte. 
evtl zählt update.exe auch dazu.
dann erwähne ich sicherheitshalber noch: update.job .
hm. sind diese programme davon betroffen?

noch was zu:
> Vorweg:
> Standardanwender sind nicht betroffen.
voll einverstanden. 

wer aber mit GROSSEN datensätzen hantiert, z.b. 
mit personen-stammdaten-sätzen, der wird sicherlich darüber 
womöglich stolpern ...
es geht um schlüssel: also indexeinträge (wenn ich das richtig 
verstehe, ich versteh ja nicht immer alles richtig ;-(  )
eine person/körperschaft, die mehr als 1000 pseudonyme hat, 
"nebeneintragungen", oder was weiss der schaitan noch alles. das ist 
doch alles "leicht" zu erreichen!

da fällt mir ein: ich hatte mal ne kirchliche bibliothek, die ist auf 
der flucht gerade in "den verbund", da hat der nichtmehrexistente 
kollege auf schaitankommraus perso-einträge mit der maus aus der zdb 
rausgeholt. und sie fleissig in den allegrodaten zur person 
reinkopiert. abspeichern ging noch. daß ein datenfeld 12.000bytes 
erreichte, hatte "er" NIE gesehen und der "kleine lehmann" später auch nicht. 
die datenbank crashte unkontrolliert, sie crashte, sie hörte gar nicht 
auf zu crashen. bis der "kleine klausi" ein werkzeug 
[hach! da haben wir es wieder: werkzeuge braucht der mensch!] 
fand: finde den kürzesten/längsten datensatz. er ging den weg, und wenn sie 
nicht gestorben sind, dann sind sie heute noch im verbund ;-)
nette geschichte! 

hm. das war ein standardanwender....

nun denn: allegro-C
wir sind alle frohen mutes und glauben

mit diesem rätsel(?)haften abschiedsgruß 
gehe ich gleich zur nächsten email ;-)

fröhlichst Ihr Klaus Lehmann.

> Es entstehen korrekt nur 1000, aber die besagte
> Adresse an der Position 1000 (also 1001), die wird eben überschrieben...
> B.Eversberg

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

Am Mittwoch, 12. November 2014 um 09:58 schrieben Sie:
> Am 07.11.2014 10:58, schrieb Klaus Lehmann:
>>
>> Die Fehlermeldung "Befehl nicht korrekt geformt" kommt bei einer acon-aufgabe mit update.job
>>
>> Der Bildschirm sieht so aus:
>> 296. Satz  :    >|9zdb82769-1<N:<E130> kein Ergebnis bei: |9 "zdb82769-1=?"
>> Befehl nicht korrekt geformt
>> EXCEPTION-Error (memory-access) in program "acon.exe" !!Drücken Sie eine beliebi
>> ge Taste . . .
>>

> Vorweg:
> Standardanwender sind nicht betroffen.

> Bereitgestellt:

>    ftp://134.169.20.101/a99.zip
>    ftp://134.169.20.101/acon.zip

> Es war ein Folgefehler. Der eigentliche Grund ist: Es entstehen bei
> einem Satz mehr als 1000 Indexeinträge.
> Der dafür vorgesehene Platz (32.000 Byte) reichte aus: die Schlüssel
> bauchten nur 24k. Aber die Zahl 1000, die war der Grund: Es wird intern
> eine Adressenliste der zum Satz gebildeten Schlüssel angelegt, und die
> ist auf 1000 dimensioniert. Nachdem aber die 999 erreicht war und der
> Schlüssel an die Liste angehängt. hat das Programm in die Adresse 1000
> schon mal prophylaktisch eine 0 reingeschrieben. Weil aber die Zählung
> mit 0 beginnt, ist die 1000 um 1 zu groß. Ob dann wirklich was passiert,
> hängt davon ab, was im Speicher hinter diesem Adressenbereich liegt
> und mit der 0 dann überschrieben wird. In diesem Fall ging's dann
> wirklich schief. Die beobachteten Meldungen weisen auf den eigentlichen
> Tatbestand nicht hin, das ist aber typisch in solchen Fällen.

> Es stellte sich bei den konkreten Daten heraus, daß der Titel
> "Bundesanzeiger" schuld war (ZDB 33414-5). Der will 1011 Schlüssel
> generiert haben. Es entstehen korrekt nur 1000, aber die besagte
> Adresse an der Position 1000 (also 1001), die wird eben überschrieben...

> Die Reparatur war kein Problem. acon.zip und a99.zip liegen bereit.
> acon für Linux müssen wir sowieso noch auf den Stand V34.7 bringen.
> Nebenbei wurde die Anzahl von Schlüsseln pro Satz in a99 und acon
> hochgehebelt auf 1200. (Und die 1201 wird nicht zum Problem, d.h.
> der Knackpunkt wird nicht einfach nur verschoben, sondern ist weg.)

> Sowas zehrt und zerrt an den Nerven von Entwicklern und betroffenen
> Anwendern gleichermaßen. Kenner zeitgenössischer Softwareparadigmen
> fragen sich (oder sogar uns) dann, warum man nicht strikt
> objektorientiert programmiere mit C++ oder, noch besser, alles in
> Java um- oder neu schreibe. Das liegt vor allem daran, daß eine
> ausgereifte und verfügbare Version von C++ 1998 erschien, Java
> wurde erstmals 1995 vorgestellt. Die allegro-Enwicklung in C++ begann
> 1985. Der Umfang der 1995 vorliegenden Codebasis war leider zu groß,
> bzw. die Entwicklungsressourcen zu klein.
> Außerden werden zeitgenössische Entwickler schon noch ein System
> hervorbringen, vor 2020, das den genannten Vorstellungen entspricht
> und allegro in mehr als nur solcher Hinsicht hinter sich läßt.

> B.Eversberg

> MfG B.E.

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