[Allegro] V32.4 und Indexparameteraufruf

[Thomas Berger]

Lieber Herr Eversberg,

>> xset.rtf dokumentiert dieses ungute Verhalten, ...
> Welches Verhalten, an welcher Stelle?

Die Frage von Herrn Fischer vorhin wird ja mehr oder weniger
beantwortet:

"Das Sperren geschieht in avanti ebenfalls automatisch nach Befehlen
des Typs find #nummer"


>> allerdings verstehe
>> ich das Muster von Werten und Vorzeichen ueberhaupt nicht,
>> eigentlich wuerde man ja "Flags" im Sinne von gesetzten
>> Bits erwarten und u.U. differenzieren negative Werte
>> verschiedene Abstufungen von "ok" und positive Werte stets
>> einen Fehler / Ausnahmebedingung.
> Ja, aber nicht alles geht gut zu machen. Der Hinweis auf "gesetzte
> Bits" war zu antizipieren, hätte aber in diesem Fall keinen großen
> Nährwert. Immerhin kann man mit
> if "-"
> den Fehlerfall ganz leicht pauschal abtesten, zu einer Marke springen
> und dort näher untersuchen.
> 
>>
>> 0 - ist stets "o.k."
>>
> Ist das eine Forderung oder ein Statement?

Eine Forderung, denn xset.rtf dokumentiert dort derzeit einen
Zustand, den ich fuer einen Fehlerzustand halte:

"Satznummer zu klein oder zu groß (Minimum 1)"


>> Fehler:
>> diverse TBL-Fehler (oeffnen, nicht vhd. Satznummer, Schreibschutz)
>> diverse ALD-Fehler (oeffnen, keine Daten, Schreibschutz)
>> Inkonsistenz (falsche Satznr. am Satzbeginn in .ald-Datei)
>> Satz geloescht / Satznr. nicht belegt
>> Regulaeres Problem beim internen .tbl-Lock: Db bereits gesperrt
>> Fatales Problem beim internen .tbl-Unlock: Db bereits freigegeben
>> Regulaeres Problem bei Lock: Satz ist bereits gesperrt
>> Fatales Problem bei Unlock: Satz war nicht gesperrt
>>
> Eine gute Zusammenfassung eines Maximalkonzepts, aber
> muß das *alles* wirklich in diesem Zusammenhang berücksichtigt werden?
> Aber OK, wir könnten das Release ja noch bis März 2013 aufschieben, da
> wären wir in guter Gesellschaft.

Ich gehe davon aus, dass acon alle diese Fehler bemerkt, ein folgendes
"if ok" scheitert sowie (der Zusammenhang sollte evtl. dokumentiert werden)
auch der alte Mechanismus "if error" bzw.  der differenzierten "if error=..."
beschickt wird.

Konkret und vordringlich stoert mich an Ihrem Entwurf:
- Nutzung von "0" als Fehlerstatus

- der unnoetige Mix aus negativen und positiven Vorzeichen

- die unidfferenzierte Meldung von "Satz war [bereits] gesperrt" (Fehler,
  auf den die Anwendung reagieren muss) = "Satz nun frei" (gemeint: "war aber
  vorher gesperrt" = kein Fehler)
  sowie von "Sperren hat geklappt" (impliziert: "Satz war vorher nicht gesperrt
  = kein Fehler) bzw. "Satz war nicht gesperrt" (groesster denkbarer Unfall)

Ich sehe hier natuerlich, wie einfach der Zustand 1/8 vor der Operation an den
Anwender durchgereicht wird, dem bleibt dann aber ueberlassen, den Wert von
sL als Fehler/kein Fehler zu interpretieren, was m.E. etwas viel verlangt ist.
Sie koennten den beiden Nicht-Fehler-Zustaenden ein negatives Vorzeichen
verpassen (ich waere allerdings fuer ausblenden), jedenfalls:

 1 set unlock gescheitert, da bereits freigegeben
[-1 set lock erfolgreich, da freigegebener Satz angetroffen

 8 set lock gescheitert, da bereits gesperrt
[-8 set unlock erfolgreich, da gesperrter Satz angetroffen]

Die Frage ist allerdings, ob der Zustand bei einem normalen, unsperrenden
Lesen als -1/8 oder -1/-8 oder 1/8 oder gar nicht vermerkt werden sollte.

viele Gruesse
Thomas Berger