[Allegro] update.job + optsget.inc überarbeitet

[Thomas Berger]

Lieber Herr Eversberg,

>> Die laufende Nummer des Satzes waere ein gewisser Schutz, muesste aber
>> in der Datenbank hinterlegt werden.
> Wieso das denn? Es geht um die laufende Nummer der Speicherung während
> einer Sitzung oder eines Jobs! Um die sonst identischen Zeitstempel zu
> differenzieren. Es geht zudem *nicht* darum, daß die #99e zweier
> verschiedener Sätze unbedingt verschieden sein müßten -das müssen sie
> nicht, denn sie werden nie verglichen! Verglichen werden nur die
> Stempel eines im Arb.Speicher von acon oder a99 befindlichen Satzes mit
> dem Stempel desselben Satzes, wie er im Moment des Speicherbefehls auf
> der Platte steht. *NUR das* ist die Funktion der #99e.

aber wie kommt er denn vorher auf die Platte, damit ich ihn vor dem
Speicherbefehl betrachten kann? Dieser Zaehler muss also von dem
(durchaus) fremden Prozess, der den Satz zuletzt gespeichert hat,
in den Datensatz hineingeschrieben worden sein, vermutlich schwebt
Ihnen da ein "als Anhaengsel an die #99e" vor.

Da gibt es dann ein gewisses Risiko, dass zwei Prozesse, die dieselbe
Update-Datei verarbeiten (aus welchen Gruenden auch immer), zufaellig
so absolut synchron sind, dass selbst dieser Job-interne Bearbeitungs-
zaehler nicht greift (anderes denkbares Beispiel: Die erste Aktion in
einer a99-Sitzung in einer hypothetischen Bibliothek ist immer das
Wegschreiben eines Protokoll-Eintrags in einem bestimmten Datenstatz).

Ich habe daher darauf hingewiesen, dass ein globaler Bearbeitungszaehler
fast ebenso einfach zu implementieren waere und eine 100%-Loesung
darstellt. Eine dritte Moeglichkeit ist ein datensatzspezifischer
Versionszaehler, wo dann bei jeder Bearbeitung "eins drauf" gesetzt wird.

viele Gruesse
Thomas Berger