Detailfragen zu acon [Was: Re: [Allegro] acon: if Del ... nach fetch record]

[Thomas Berger]

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

Lieber Herr Eversberg, liebe Liste,

> jetzt geht's also, wie bei a99, genau so:
> Wenn die einzulesende Datei vom Typ .ALD oder .LOG ist!
> Sonst sind die ersten zwei Zeilen wegzulassen, das muß man im
> eigenen Job beachten, also normalerweise beim Öffnen der Datei
> prüfen, welcher Dateityp es ist.
> 
> fet b     // erstes Byte = Status 1,8,9
> fet b4    // interne Satznr
> fet rec   // Satz
> 
> und anschließend steht die int. Satznr. trotzdem zusätzlich in iR,
> aber auch nur bei .LOG und .ALD, sonst ist sie sinnlos.

ja, obwohl das dreischrittige Vorgehen so aussieht, als koenne es
nicht passieren, ist nach "fetch record" auch noch etwa #u1 belegt.
Mal sehen ob es sich irgendwann raecht, dass hier "Magie" uebrig
geblieben ist, momentan habe ich kein Problem damit.

Nun kann - in den einfachen, mit SRCH -F vergleichbaren Faellen -
umittelbar hinter "fetch record" ein "srX" durchgefuehrt, und bei
Misserfolg direkt der naechste Satz untersucht werden. D.h. hier
greifen deutliche Abkuerzungen im Vergleich zur Normalbehandlung,
wo der gelesene Satz mittels "new" und "insert" zu einem neuen
Satz im Arbeitsspeicher wird, der dann mit "copy obj" kopiert
wird, damit man eine Arbeitsversion hat, die vom anschliessenden
set a5 veraendert werden darf, diesen Satz kann man mit "var kn"
dann zurueck in die iV holen und mit srX ebenfalls testen...

Frage zur Effizienz: Angenommen ich habe einen "Datensatz" in
der iV, ein damit den Kategoriespeicher fuellendes "insert" hat dann
vermutlich einige Kosten. Was ist guenstiger, wenn man eine Kopie
haben moechte:

 // Kopie des Satzes
copy obj1 2
switch obj

 // oder erneutes insert
switch obj
new
insert

Lassen sich die Unterschiede quantifizieren (wenn die meisten Tests negatives
Ergebnis haben, benoetigt man die Sicherheitskopie gar nicht, da nichts
exportiert wird und das eigentlich etwas langsamere koennte sich als effizienter
erweisen)?


Noch eine Frage: Ich habe den Eindruck, dass "Write" oft den Inhalt der iV
zerstoert (genau dann, wenn dort CStrings *mit* folgenden Manipulationen (...)
vorkommen?).
Soll das so sein bzw. gibt es eine Liste von Befehlen, die die iV erhalten oder
zerstoeren (oft ist es ja dokumentiert, wie bei "fetch")?



> D.h., Herr Berger, der momentan vorliegende Entwurf von srch.job
> ist zu überarbeiten.

das ist geschehen, bitte testen.

Man kann nun schoen spielen, etwa eine .log-Datei nach .alg umwandeln
und anschliessend nach adt. Oder zunaechst nach .adt und dann nach
.alg: Dabei trifft man auf ein altbekanntes Problem:

Fuer "fetch record" (auch fuer "read"? auch bei a99?) ist der Trenner
zwischen zwei Datensaetzen nicht die Leerzeile, sondern das Auftreten
der Primaerschluesselkategorie (und es gab schon immer Probleme, wenn
die nicht belegt war, etwa bei Exemplarsaetzen). Liest man daher eine
nach .ADT umgewandelte Logdatei ein (enthaelt #u1), so besteht der
"Datensatz", der in der iV ankommt, nur aus #u1 (und ihrem Inhalt), denn
diese kommt *vor* der Schluesselkategorie #00.
Der Rest wird wohl als naechster Datensatz interpretiert, aber nie
eingelesen (das naechste "fetch record" liefert wieder #u1, die
Leerzeile hat wohl auch eine Wirkung). Nach ca. 150 Satzen crasht
acon:

neuer Satz      0/84+0
neuer Satz      0/85+0jp=e

J:<E120> Label export not found
EXCEPTION-Error (memory-access) in program "acon.exe" !!

(Label "export" ist das, wo in den Saetzen zuvor der Export
stattgefunden hat, hier wird also zunaechst der interne
Speicher ueberschrieben, in dem der Job repraesentiert wird)

Also:
- - acon darf nicht crashen, auch nicht bei Schrottdaten

- - acon darf erst recht nicht bei legitimen Daten crashen

- - Datensatztrenner im Externformat sollte(n) ausschliesslich
  die Leerzeile(n) sein, nicht eine Schluesselkategorie.


Noch eine Nachfrage: Fehlermeldungen bei 'dir' deuten darauf hin,
dass hier eine Shell aufgestartet wird und ein externes Kommando
ausgefuehrt? Kommentare in srch.job legen nahe, dass das unter
Unix irgendwie anders ist (oder nur darauf, dass hier Wildcards
in der Kommandozeile bereits vom Betriebssytem expandiert werden,
wenn man sich ungeschickt anstellt?) Ist das noch Baustelle oder
lohnen sich gruendliche Tests?


Unsicher bin ich mir bei folgendem: Sie hatten vorgestern
beschrieben

> Was wir aber endlich eingebaut haben (wie schon lange in a99) sind
> "export Head" und
> "export Foot".

und bevor ich eigene Tests mache, wollte ich nachfragen, was hier
automatisch passiert und was tatsaechlich durch die nun moeglichen
expliziten Aufrufe geregelt werden muss. Im Handbuch steht ja z.B.,
dass der Fussteil automatisch alle x Zeilen gebracht wird, wenn zl
nicht 0 ist.
Fragen u.a.: Wird der Fussteil ueberhaupt nach dem letzten Datensatz
  ausgeworfen oder immer nur, wenn eine "Seite voll" ist (zumindest
  bei zl <> 0?
* Wird der Kopfteil unter acon automatisch ausgeworfen (etwa beim
  ersten "export" in eine neue Datei, mit einer neuen Parameterdatei,
* Wird der Fussteil automatisch beim Schliessen der Datei ausgeworfen,
  oder beim Entladen der Parameterdatei?

Dringender als die Frage nach den Sonderabschnitten K und F ist eigentlich
die nach den besonderen Nicht-Sprungmarken "#" (GM) und " " (Exportende):

Wird "dow w#" funktionieren und den GM-Abschnitt ausfuehren? Was passiert,
wenn die Sprungmarke in den aktuell geladenen Parametern nicht existiert?

Bzgl. Exportende / Endabschnitt dasselbe,

vgl. zuerst (obwohl auch dort schon "bekanntlich")
http://sun250.biblio.etc.tu-bs.de/pipermail/allegro/1999-August/007209.html

oder zuletzt
http://sun250.biblio.etc.tu-bs.de/pipermail/allegro/2008-August/028412.html



Bezuglich Performance habe ich den Eindruck, dass alles nun noch viel langsamer
ist, ein paar Messungen mit acon -j srch.job bzw. SRCH.exe (Zahlen immer noch
nicht unbedingt vergleichbar)

                                      srch.job    SRCH.EXE
1. -F und unmoeglicher Suchbegriff      40'          30'

2. Vollexport -f6/-s0 mit i-1 (*)       69'         100'

3. unmoeglicher Suchbegriff (**)        92'         168'


[* Es gibt also keinen Vergleich, und Datensaetze werden weder nach dem
Einlesen noch fuer den Export v14-expandiert

[** Datensaetze werden also (-F fehlt) vor dem Vergleich v14-expandiert


Vergleich von 2. mit 1. belegt moeglicherweise, dass "insert" und "export"
(selbst bei trivialer Parameterdatei i-1) extrem kostspielig sind (im
SRCH-Fall misst man aber evtl. nur die IO-Beschraenkungen des 16bit-Teilsystems,
immerhin werden hier einige GB Daten durchgenudelt)

Ich habe (***) aber den Eindruck, dass das Laufzeitverhalten von acon stark von
der Groesse des Jobs / Anzahl der Befehle oder Anzahl der Zeilen oder mit der
Anzahl der genommenen Spruenge abhaengt. Vorsichtshalber nachgefragt: Wird
bei einem "jump" die Zielsprungmarke jedes Mal ~gesucht~ oder ist sie seit dem
Einlesen der Job-Datei *bekannt*? [Die Exportsprache erinnerte mich haeufig
an Assembler, z.B. die relativen Jumps "#xy +#kkf ...". Die FLEX- und Job-
sprachen fallen hier deutlich ab, z.B. weil man 5 Anweisungszeilen benoetigt,
um einen simplen Zaehler zu inkrementieren. Jedenfalls benoetigt man in FLEX/JOB
ungleich mehr Anweisungszeilen als in der Exportsprache, um vergleichbare
Probleme zu loesen.

[*** vorsichtiger Vergleich legt nahe, dass in den Zahlen fuer srch.job jeweils
etwa 35' Overhead enthalten sind (wenn man unterstellt dass SRCH.EXE wenig
Overhead hat und wg. IO-Restriktionen einfach nur "gleichmaessig" langsamer
ist). Das heisst aber, das Optimierungspotential im Fall 1. ist ca. 85%. Von der
Indexierung dieser Datenbank weiss ich:
- - at 1  6' (vergleichbar 2.)
- - at 2 71' (beinhaltet v14-Expansion, also 3. plus viel Rechnen)


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

iJwEAQECAAYFAkwZ2okACgkQYhMlmJ6W47O6KAP/YCOhGu9VpZ+90y5u6uoyLcI0
rvN57fPEuh3QKaTmp4C7uDW/sAiZ/a/tcn0K78Y/co2D5w6BSoisTQtuTOaNu+pP
4DHPTqCWzilprqXPElUfVzW7d3o+HtBcY8kpr0qwRrGbJLyjv8wRrerM821VADhE
F0ZPBjzY6rqsqDAIyJM=
=v908
-----END PGP SIGNATURE-----