[Allegro] srch.job jetzt deutsch kommentiert

[Anando Eger]

Hallo Herr Eversberg,

ich schlage eine kleine Verbesserung für den srch.job vor:

statt
-----------------------------------------------------
...
// Indikator für Dateityp setzen: .Xld, .log, .Xlg, .Xdt 
var $fn "x"
if %ldx% #uld 1
if %lgx% #ulg 1
if %ogx% #uog 1
if %dtx% #udt 1
...
-----------------------------------------------------
besser
-----------------------------------------------------
...
var $fn (0,-2)
if "ld" #uld 1
if "lg" #ulg 1
if "og" #uog 1
if "dt" #udt 1
...
-----------------------------------------------------
Das würde Fehler bei Dateinamen wie z.B. "bdtxx.ald" ausschließen.

Viele Grüße
Anando Eger

-------------------------------------------------------------------
Anando Eger Datenverarbeitung
Herr Dipl.-Ing. Anando Eger
Alsenstr. 3
01157 Dresden

Tel.: +49 (0)351 454 1236  http://www.aneg-dv.de
Fax: +49 (0)351 454 1238  mailto:a.eger at aneg-dv.de
-------------------------------------------------------------------
== Wir sprechen deutsch. ==



Kollege Lehmann hatte ja recht gestern mit seiner harschen Kritik am 
srch.job.
Es wurde also nochmals revidiert, korrigiert,  meliorisiert und 
schlußendlich auch komplett auf deutsch kommentiert.
Hier das Endergebnis:
  http://www.allegro-b.de/files/job/srch.job
oder zum Abholen per a99:  X gf srch.job

Lehmann hat auch auf den srch.job von 2016.
Der arbeitet korrekt, was nicht verwundert, stammte er doch aus der 
Feder von Thomas Berger. Sein Nachteil ist seine Langsamkeit, was 
ein Anstoß war für die Neukonzipierung mit dem neuen srch.job als 
Ergebnis, der gut 10mal so schnell ist.

Der neue deutsche Kommentar ist sehr ausfuehrlich, es sind insgesamt 
100 Zeilen von 256. Der eigentliche Code ist also gar nicht soo 
umfangreich, sogar deutlich weniger als der alte von 2016.
Weitere Worte sind an dieser Stelle nicht nötig, denn der srch.job 
beginnt mit ausführlicher Darlegung zu seiner Anwendung, auch mit 
Hinweis auf srch.exe und wie der Startbefehl im Vergleich aussieht.
Der a35srch.job bleibt hiervon unberührt! Er funktioniert klaglos 
schon in einigen Anwendungen von a35.
Ein Kernstsück des srch.job ist die Methodik der Abarbeitung der 
Datendateien: sequentiell statt Satz für Satz in der Reihenfolge der 
internen Satznummern. Das braucht viel länger, weil VIEL mehr 
Dateizugriffe nötig sind: für jeden Satz erst die Dateinummer und 
Position aus der .tbl holen, dann die betr. Datendatei öffnen und zu 
der Position gehen, dort den Satz auslesen, Datei wieder schließen.
Wenn man nur wenige tausend Datensätze hat hat oder selten 
Volltextsuche macht und zufrieden ist mit dem alten Job, kann man 
dabei bleiben. Es war eine wachsende Unzufriedenheit bei großen 
Datenmengen (hundertausende von Sätzen), was, wie gesagt, einen 
Anstoß gab. Hinzu kommt das Potential für eigene Erweiterungen, was 
dem alten srch.job noch nicht innewohnt.


-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://bibservices.biblio.etc.tu-bs.de/pipermail/allegro/attachments/20200424/b27e0005/attachment-0001.htm>