[Allegro] acon + update.job neu bereitgestellt

[Thomas Berger]

Lieber Herr Eversberg,

>>> -- acon macht selber vor dem Speichern die globale Manipulation,
>>>     wenn ein Export eingestellt ist und eine Marke #-# enthält
>>>     Dies kann aus  update.job  somit raus.
>>
>> was passiert, wenn es drin bleibt?
>>
> Kommt drauf an, was die Prozedur tut! Sie wird ja dann zweimal ausgeführt. Gäbe
> es einen Grund, den bisherigen update.job weiter
> zu nutzen? Sie könnten das sogar machen, dann aber die Sprungmarke
> anders nennen, so daß acon dann nichts täte.

update.job gibt es nur, um update.exe zu emulieren.

"Im Feld" sind diverse Versionen von update.job, die nur mit acon
bis etwa Januar 2012 funktionieren, und dann wird es neuere
update.job geben, die nur mit zukuenftigen acons funktionieren.

Ich halte die Gefahr fuer real, dass Anwender (nicht des GP, aber
andere) in eine Situation mit neuem acon und altem Update.job kommen,
oder sogar umgekehrt (einfacher Fall: Der neue Update.job muss die
acon-Versionsnummer erfragen und sich weigern zu arbeiten, wenn die
zu alt ist). Daher meine Fragen, ob aeltere Update.job (mit get edit
und Expliziter Ansteuerung von #-#) mit neueren acons zusammenarbeiten
werden koennen.


>>> -- update prüft vor dem "put", ob der Satz gesperrt ist. Wenn ja,
>>>     wird nichts weiter versucht, sondern der Satz in  upro  kopiert
>>>     mit entsprechender Meldung
>>
>> Nicht nur PRESTO, sondern auch andere allegro-Module koennten einen
>> Satz gesperrt haben, schliesslich gibt es die entsprechenden
>> Funktionen in der Flex-Sprache. Insofern sollte dieser Test entfallen.
> Er *kann* entfallen. Was wir erst mal rausgenommen haben, ist der
> mehrfache Versuch mit Zeitverzögerung.
> 
>> (Bzw. "upro": bezog sich dieser Abschnitt auf das Flex-Kommando
>> "update"?)
> Das kommt im  update.job  nicht vor.

O.k., also update.job. Ein "Vorab-Test" auf gesperrte Saetze macht
wenig Sinn, allerdings sieht man hier deutlich, dass man einen
definitiven Test ("get edit") bereits beim Einlesen des Satzes
benoetigt, nicht erst beim "put".



>> Hier schon oft angesprochen und begruendet: Das Standardverhalten sollte sein,
>> dass update (nicht "put") es immer weiter versucht, auch auf die Gefahr des
>> "Aufhaengens".
>>
> Darüber kann man nochmal reden, im update.job jedenfalls kommt "update"
> nicht vor, nur "put".

Sorry: Hier meinte ich genau wie Sie mit "update" die Steuerdatei
"update.job"



>>> Die nötigen Sperrungen, m.a.W., erfolgen jetzt nur noch intern, darum
>>> braucht man sich nicht mehr zu kümmern.
>>
>> Das KANN nicht funktionieren: Wenn in den entsprechenden Update-Modi
>> Saetze gemergt werden, muessen ihre "online"-Versionen beim
>> Einlesen gesperrt werden, beim (waehrend des) "put" ist es zu spaet.
>>
> Beim "put" wird der Zeitstempel geprüft, vergessen Sie das nicht! Bei
> Ungleichheit keine Speicherung, sondern Meldung und Kopie des Satzes in
> upro. Wenn also zwischen Einlesen und "put" was passiert war, wird das
> abgefangen, und zwar ja nun auch, wenn's weniger als 1000 Millisekunden
> waren.

Wenn aber doch das Verwerfen des Satzes inakzeptabel ist, muesste
ich an dieser Stelle den Originalzustand des Datensatzes aus der
Update-Datei erneut herbeiholen und die gesamte Verarbeitung neu
durchfuehren. Inklusive Korrektur aller Zaehler, damit ich nicht
hinterher scheinbar einen Datensatz mehr bearbeitet habe als in
der Datei vorkamen. Das wird ein enormer Aufwand fuer update.job
(eine Art Rollback-Mechanismus), nur weil Sie denken, ohne
"get edit" auskommen zu koennen.



>>> Reservierung oder sowas wie "set lock" oder "get edit" erübrigt sich
>>> damit im update.job!
>>
>> Und was passiert, wenn es drin steckt?
>>
> Weiß ich nicht. In der neuen Version steckt es nicht drin.
> 
>>
>>> Nebenbei:
>>> Das alte UPDATE.EXE warf die Meldung "Satz gesperrt" aus, wartete
>>> ein wenig, usw. Nur Freigabe des Satzes durch den Admin führte zur
>>> Weiterarbeit. Falls das für besser gehalten wird, könnten wir
>>
>> Nur so kann man sich darauf verlassen, dass nach dem Ende des Updates
>> alles geschehen ist, was haette geschehen sollen.
>>
> Kommt drauf an! Wenn der PRESTO-Nutzer gerade einen Satz änderte und
> dieser dann vom "put" nochmals geändert wird, geschieht u.U. nicht das,
> was geschehen hätte sollen. Ist es da nicht besser, wenn der Satz in
> upro landet und man sich das nochmal anschauen muß/kann, anstatt sich
> blind drauf zu verlassen?

Wenn sichergestellt ist, dass die Grundlagen fuer acon's put (neben
der Version des Datensatzes aus der Update-Datei) die vom Benutzer
abgespeicherte Version ist, ist das Problem auch nicht anders gelagert
als eine Bearbeitung, die vor einer Stunde stattgefunden hat. Oder
die in einer Stunde stattfinden wird.

viele Gruesse
Thomas Berger