[Allegro] Acon: Kein Entsperren am Ende des Jobs?

[Sibylle Koczian]

Lieber Herr Eversberg, liebe Liste,

Am 08.01.2013 08:27, schrieb Bernhard Eversberg:
> Am 31.12.2012 15:46, schrieb Sibylle Koczian:
>>
>> Daraus würde ich eigentlich schließen, dass ein Satz _nicht_
>> gesperrt zurückbleiben sollte, wenn ein Acon-Job
>>
>> - ihn mit f1nd sucht und lädt - auf "if no" mit einer Fehlermeldung
>> reagiert - ein paar Kategorien ausgibt
>>
>> und sonst nichts. Kein Ändern, kein Speichern, und auch kein
>> Übergang zu einem nächsten Satz.
>>
> So ist es (vorsichtshalber schnell mal getestet)
>
Die weitere Diskussion hat das Problem eingegrenzt. Wie von Herrn Berger
sofort vermutet, hatte ich Entscheidendes nicht gesagt: bei dem Ausgeben
von "ein paar Kategorien" wird ein Stammsatzkürzel aufgelöst. Und da
gibt es, mit dem aktuellen acon.exe vom 9.10.12, tatsächlich ein Problem.

Ich zitiere mich mal selber (Nachricht vom 2.1.13):
> Auszuprobieren an der Demo-Datenbank mit dem folgenden kleinen Job:
>
> f1nd TIT tucho?
> set a1
> write #00 ": " #31p n
>
> Dabei den Befehl "set a1" mal auskommentieren, mal aktiv lassen und
> hinterher in a99, z.B. mit "h org", den Sperrzustand des gefundenen
> Satzes überprüfen.
>
> Ein "set unlock" am Ende des Jobs entsperrt den Satz. Aber soll das
> so sein oder nicht? Ich nehme an, das Verhalten hängt damit zusammen,
> dass ein Satz nach der Stammsatz-Auflösung ja nicht mehr gespeichert
> werden darf. Allerdings lässt "find" statt "f1nd" den Satz nicht
> gesperrt zurück. Sucht man im gleichen Job mehrere Sätze
> hintereinander mit f1nd, sind sie hinterher alle gesperrt (und ein
> "set unlock" am Ende entsperrt nur den letzten).

Ein A99-Flex mit f1nd und "export Ref" lässt keinen gesperrten Satz 
zurück, speichert allerdings den veränderten Satz, wenn man die Warnung 
in der Dokumentation nicht beachtet. Das bestärkt mich in der Vermutung, 
dass das Nicht-Entsperren mit dem Nicht-Speichern zusammenhängen könnte.

> acon kennt keine Setzungen, anders als a99, die über den Ablauf
> eines Jobs fortgelten. Denn acon hat kein Sitzungskonzept, wie a99.
> Jeder Job beginnt frisch mit allen Default-Einstellungen. Insofern
> kann die Angabe [perm] in xset.rtf den Leser an der Stelle
> irreführen.
>
Sie ist allerdings erklärt. Das hätte ich mir also eigentlich gleich
richtig vorstellen können. Ist egal, weil die ganze Überlegung mit "set
getlock" sowieso falsch war.

Beste Grüße,
Koczian