<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"></div><div class="gmail_default" style="font-family:monospace,monospace">Kollege Lehmann hatte ja recht gestern mit seiner harschen Kritik am srch.job.</div><div class="gmail_default" style="font-family:monospace,monospace">Es wurde also nochmals revidiert,  korrigiert, 
meliorisiert

 und schlußendlich auch komplett auf deutsch kommentiert.</div><div class="gmail_default" style="font-family:monospace,monospace">Hier das Endergebnis:</div><div class="gmail_default" style="font-family:monospace,monospace">  <a href="http://www.allegro-b.de/files/job/srch.job">http://www.allegro-b.de/files/job/srch.job</a></div><div class="gmail_default" style="font-family:monospace,monospace">oder zum Abholen per a99:  X gf srch.job</div><div class="gmail_default" style="font-family:monospace,monospace"><br>Lehmann hat auch auf den srch.job von 2016.<br></div><div class="gmail_default" style="font-family:monospace,monospace">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.<br><br></div><div class="gmail_default" style="font-family:monospace,monospace">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.</div><div class="gmail_default" style="font-family:monospace,monospace">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.</div><div class="gmail_default" style="font-family:monospace,monospace">Der a35srch.job bleibt hiervon unberührt! Er funktioniert klaglos schon in einigen Anwendungen von a35.<br></div><div class="gmail_default" style="font-family:monospace,monospace">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. <br></div><div class="gmail_default" style="font-family:monospace,monospace">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. <br></div><div class="gmail_default" style="font-family:monospace,monospace"> <br></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div></div>