[Allegro] update.exe / 32bit

[Thomas Berger]

Liebe Liste,

B. Eversberg schrieb:

> Also wenn einer mit !!! nach einem neuen Program exklamiert, das nun
> wirklich nicht aus dem Boden zu stampfen ist - und dies sollte man mir
> schon bitte abnehmen - dann indigniert mich das etwas. Und das nachdem
> die Abhilfe nun schon mehrfach deutlich erklärt wurde, was aber
> anscheinend, wenn nicht gar überlesen, dann noch nicht einmal probiert
> wurde.

Einerseits habe (auch) ich schon lange darauf hingewiesen, dass
sich die Einsatzfaehigkeit von SRCH und UPDATE rapide ihrem Ende
naehert (wegen der 64bit-Betriebssysteme) und selbst perfekt die
Funktionalitaet nachbildende srch.job und update.job einen
gewissen Anpassungszwang erfordern, weil es eben nicht immer
nur mit der Ersetzung "srch" durch "acon -jsrch" getan ist,
bzw. ja selbst diese Ersetzung Anwender vor Probleme stellen
kann. Daher habe ich es auch sehr begruesst, dass es ploetzlich
doch ging und Braunschweig ein srch32 aus dem Hut gezaubert hat
(und dank der seit gestern vorliegenden Quellen rechne ich mir
auch gute Chancen aus herauszufinden, warum es gerade bei meiner
einen Monster-Datenbank nicht funktioniert).

Andererseits ist es befremdlich (aber natuerlich real), dass
Anwender anscheinend allerorten erstens selbstgestrickte .bat-Dateien
haben, in denen die Aufrufe fuer Exporte nicht durch ein allgemeines
allegro-Upgrade von selbst umgestellt werden, und zweitens dann irgendwie
nicht in der Lage sind, diese selbstgemachten Dateien ausfindig
zu machen und anzupassen. Ich selber kenne allegro-HANS, wo die
Aufrufe "unter der Haube" umgestellt wurden (mit einer gewissen
Vorsicht, denn auch aktuelle Parameter koennen mit einer zugrunde-
liegenden allegro-Version 25 oder so konfrontiert werden), oder
auch eine Bibliothek, wo die Systembetreuerin vor 10 Jahren
verstorben und Ersatz nicht in Sicht ist (aber da laeuft auch noch
allegro v12.3 und es wird dort nie ein acon aufschlagen, insofern
brauchen sie auch nie etwas anzupassen).

Es ist einfach so, dass wer einmal allegro installiert hat, Jahre
spaeter nach dem Umzug auf einen neuen Rechner ein Versions-Upgrade
benoetigt, weil das mit den 16bit-Modulen einfach nicht mehr klappt.
Und wer einmal etwas angepasst hat, muss bei jedem Upgrade damit
rechnen, dass er seine Anpassungen erneut vornehmen oder zumindest
auf Funktionsfaehigkeit ueberpruefen muss. Vor etwa 10 Jahren ist
vielen Enthusiasten aus den fruehen 90er-Jahren die Sache ueber
den Kopf gewachsen und sie haben nachtraeglich bereut, so viele
Aenderungen vorgenommen zu haben (insbesondere wenn es dann auch
noch fuer "befreundete" Bibliotheken erfolgt ist). Das hat nicht
so viel damit zu tun, dass alles im Laufe der Jahre immer schwieriger
geworden ist, sondern z.B. mit dem Peter-Prinzip, veraenderten
Arbeitsbedingungen in Bibliotheken und eben der Erkenntnis, dass
jede selbstverantwortete Reparatur, Aenderung oder Erweiterung
eine Mikro-Verpflichtung auf unbestimmte Zukunft bedeutet, in der
Summe kann da einiges zusammenkommen, je produktiver man in
frueheren Zeiten war, umso belastender ist das in der Gegenwart.
(Erfolgreiche Autoren koennen sich Sekretaere leisten, um die
Fanpost zu beantworten, aber "erfolgreiche" Systembibliothekare
scheinen in einer anderen Liga zu spielen)

Herr Eversberg deutete an, dass ein generalueberholtes Update.exe
analog srch, import und index nicht so einfach ist, vermutlich
liegt das daran, dass die bisherige Generalueberholung nur
Programme betraf, die die Datenbank ausgelesen haben bzw. maximal
noch in die Indexdatei schrieben).

Ich sehe einen Unterschied zwischen srch und update bzw. die
Priorisierung aus einem anderen Blickwinkel:
Es besteht wirklich Bedarf an einer *schnellen* Volltextsuche
(mit Indexzugriffen und Nachladungen), den eine acon-Loesung
(derzeit) nicht abdecken kann. Was aber Update betrifft, also ein
Programm das massenhaft in die Datenbank schreibt, so ist hier
die Performance eher durch den Durchsatz beim Schreiben und das
generelle Design von Update gebremst.
Das alte Update hat erstaunliche Moeglichkeiten im Zusammenhang
mit zugeschalteten Parameterdateien (die auch unter acon
funktionieren), die waren aber so knifflig in den Griff zu
bekommen, dass sie wohl kaum jemand genutzt hat. Es sind
Anwendungszenarien denkbar, die (etwa als eine Art globale
Manipulation) auf einem intensiven Wechselspiel zwischen
Lesen aus der und Schreiben in die Datenbank beruhen, aber
das Update, wie wir es kennen, haette eben auch in der
runderneuerten Version nur die alte Funktionalitaet und da
bietet sich ein Schnitt bzw. die groessere Flexibilisierung
durch .job-Dateien, wie sie acon bietet, geradezu an (ein
Job kann die Kompatiblitaet mit dem alten UPDATE gewaehrleisten,
und x Jobs implementieren neue Vorgehensweisen).



> Und was Sie schrieben:
>> "acon ist in der
>> Installation viel komplizierter als ein Programm, das brav auf dem
>> Server liegt und wartet, bis es von irgendwo aus dem Netz aufgerufen
>> wird..."
> 
> das beruht nun mal auf einem Mißverständnis und stimmt nicht.

Ich will das auch nicht spekulativ entwirren und auch nicht die
verschlungenen Wege rekapitulieren, wie es dazu kam, der Ist-
Zustand ist allerdings, dass es seit einiger Zeit ein nicht-
interaktives Programm namens acon gibt, das sich in den
beliebten Zoo von import, index, qrix, srch und update, also
der Batch-Programme, die eine der Staerken von allegro sind,
einreiht:

Es liegt im Programmverzeichnis, kennt mehr oder weniger die
ueblichen Kommandozeilenschalter und kann Parameterdateien
nutzen, die es nach den bekannt komplexen Mechanismen aufzuspueren
in der Lage ist. Der Unterschied ist allerdings, dass alles
zwingend unter Kontrolle eines "Jobs" ablaeuft (also einer in
einer leichten Variante der Flex-Sprache von a99 geschriebenen
Steuerdatei), das macht es einerseits sehr flexibel, anderseits
muss man so einen Job erst einmal haben. Insofern hilft einem
ein im Programmverzeichnis sitzendes acon auch noch nicht so
viel wie srch, denn die konkrete Funktionalitaet wird eben
erst durch die Jobs realisiert, derzeit gibt es da nur - srch.job
und update.job.

Diese Sicht- und Nutzungsweise ist recht stark abweichend vom
bislang als "avanti" bekannten Modus operandi: Hier werden
- unter Client/Server-Paradigmen - von Middleware adhoc solche
Jobs konstruiert, die Suchbegriffe oder Kategoriebelegungen etc.
dann fest enthalten und damit exakt fuer diese eine Aktion zu
diesem einen Zeitpunkt konstruiert sind. Dementsprechend werden diese
Jobs auch nicht unter irgendeinem Namen irgendwo abgespeichert,
sondern direkt als "Standard-Input" dem verarbeitenden Programm
in den Rachen geworfen, dieses Programm heisst an einem Ende
avanti und am anderen Ende acon (und ist es auch).

Dass es auch unter "avanti" anders denkbar ist, zeigt m.E. der
a30-Ansatz: Hier sind die Jobs wesentlich undynamischer, also
einerseits statisch in Dateien hinterlegt, andererseits sind
diese aufwendiger und universeller realisiert: Gesteuert wird
das dann eher klassisch im Sinne von Aufrufparametern, also
vorbelegungen gewisser Variablen (ich habe mir das aber lange
nicht mehr angesehen). Ein fester Job kann also - unterschiedliche
Eingangswerte vorausgesetzt - unterschiedliche Ergebnisse liefern,
ganz wie gewuenscht. Der Vorteil dieses Ansatzes ist dabei,
dass fuer neue Funktionalitaeten dann nicht unbedingt die
Middleware ueberarbeitet werden muss, sondern (i.W.) nur eine
(geeignete, zu schaffende, geeignet beschaffene) Job-Datei am
zentralen Ablageort zu ergaenzen ist.

viele Gruesse
Thomas Berger