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

[Sibylle Koczian]

Lieber Herr Berger, liebe Liste,

Am 31.12.2012 16:48, schrieb Thomas Berger:
> Liebe Frau Koczian, liebe Liste,
>
>> in der Dokumentation zu "set lock/unlock" heißt es:
>>
>> "Automatisch, etwa vor dem Laden des nächsten Satzes oder am Ende des Jobs,
>> wieder freigegeben wird der Satz nur in avanti, aber in a99 nicht, d.h. da muß
>> man das mit  set unlock  selber tun."
>>
>> 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.
>
> ... und insbesondere kein Sperren ...
>
> Haben Sie da etwas entscheidendes nicht geschildert? Nach meiner Erinnerung
> war es nur fuer ganz kurze Zeit in diesem Sommer so, dass acon stets gesperrt
> hat (ich habe das aber laenger nicht getestet und im Quellcode nachgeschaut)
>

Explizites Sperren und/oder Entsperren im Job findet nicht statt. Aber 
gesucht wird mit _f1nd_ und das sperrt (sagt die Dokumentation und passt 
zu dem, was ich sehe). Genauer (siehe "set getlock"):

"Das Sperren geschieht in avanti ebenfalls automatisch nach Befehlen des 
Typs  f1nd ... und  get ...  aber nur wenn  set getlock on  gesetzt ist."

Ich gehe davon aus, dass "getlock on" Default ist, sonst könnte ich mir 
meine Ergebnisse nicht erklären. Aus der Dokumentation allein wird mir 
allerdings nicht klar, wie der Normalzustand sein müsste.

Ich habe jetzt versucht, die Sperr-/Entsperr-Tätigkeit von f1nd mit "if 
Lock" und Abfragen von sL zu testen, es bleiben Unklarheiten. Ich mache 
daraus eine eigene Nachricht, sonst wird das hier zu lang.

>
>> Ein Python-Skript führt diesen Job mehrmals hintereinander mit wechselnden
>> Suchbegriffen aus. Und hinterher stelle ich fest, dass die Sätze, die dabei
>> gefunden und ausgegeben wurden, sehr wohl gesperrt sind.
>
> Bezueglich automatischem entsperren gab es auch einiges an Hin- und her,
> insbesondere wenn der Satz weggeschrieben wird - manchmal muss er dann
> gesperrt bleiben. Und es soll auch moeglich sein, einen Satz zu sperren,
> irgendetwas anderes zu tun (andere Satze heranziehen) und dann erst
> wieder zu entsperren. Insofern ~sollte~ die Faustregel sein, dass Saetze,
> die explizit im Job gesperrt wurden, auch explizit wieder freizugeben
> sind.
>

Davon würde ich auch ausgehen. Die Frage ist, ob die Benutzung von f1nd 
in diesem Sinn ein explizites Sperren darstellt.

Ich erinnere mich an die Diskussion, habe sie allerdings nicht wirklich 
genau verfolgt. Dass ein Satz, der nur gelesen wurde, in Abhängigkeit 
von der Art der Suche (f1nd - find) gesperrt zurückbleiben kann, wäre 
mir aber vermutlich aufgefallen, wäre davon ausdrücklich die Rede gewesen.

>
>> Zwei Nebenfragen: die Sätze, die ich brauche, lassen sich nicht auf vernünftige
>> Weise zu einer Ergebnismenge zusammenfassen. Ich könnte allerdings einen langen
>> String konstruieren, der innerhalb des Jobs in die einzelnen Suchbegriffe
>> zerlegt werden müsste. Hätte das Vorzüge?
>
> Im Gegensatz zu einem Feature, das Ergebnismengen vergroessern kann?
>
Im Gegensatz zu meinem aktuellen Vorgehen, in dem ein Python-Skript 
verschiedene Acon-Jobs nacheinander ausführen lässt: Job 1 bildet eine 
Ergebnismenge und gibt pro Satz ein paar wenige Informationen aus. 
Gerade genug, dass das Python-Skript daraus je einen Suchbegriff bilden 
kann, der zu jedem Satz der ursprünglichen Menge mittels Job 2 genau 
einen _anderen_ Satz findet, aus dem dann die eigentlich gesuchte 
Information gelesen wird. Es kann sein, dass mehrere Sätze der in Job 1 
gebildeten Menge auf den gleichen "eigentlich gesuchten" Satz führen; 
das ist in Python sehr leicht abzufangen, ich bezweifle, dass es 
innerhalb eines Acon-Jobs ebenso einfach wäre.

>
>> Und bei dieser Variante könnte ich mit "set getlock off" das Sperren der
>> einzelnen Sätze von vornherein abstellen. Muss das dann am Ende explizit wieder
>> gesetzt werden oder passiert das am Ende des Jobs automatisch?
>
> Ah, das Feature hatte ich verdraengt. Also, wenn Sie "set gettlock on"
> setzen, kann es durchaus sein, dass Sie die erste sind, die dieses
> Feature nutzt und die zugehoerige Entsperrlogik nicht in acon implementiert
> ist, also in den Job gehoert...
>

Meine Frage ist umgekehrt (ausgehend von der Vermutung, dass "getlock 
on" Default-Einstellung ist, siehe oben): ich würde das Sperren 
abstellen wollen und weiß nicht, ob ein solches Abstellen den Job 
überleben könnte. Dass ich ein explizites "set getlock on" auch wieder 
explizit abstellen müsste, davon bin ich bis zum Beweis des Gegenteils 
überzeugt.

Ich werde jetzt erst mal einerseits die zum Thema passende Verlautbarung 
zu finden versuchen und andererseits noch etwas testen.

Beste Grüße,
Koczian