SETGT + %EQUAL

[rscheppe]

Noch eines ist mir jetzt nicht klar (wir haben noch V5R3 im Einsatz):
ein %Found(), %Equal() etc. bezieht sich, da ohne Datei- Angabe, m.E. doch stets auf die letzte Operation, die einen solchen Wert verändern kann und damit auf die letzte betroffene File, oder? Siehe Beispiel von Herrn Fürchau + Antwort von Frau Hauser---

Ansonsten allen Dank, die Antwort von Pikachu war ja auch i.O., nur wollte ich gern auf eine weitere Datei, wenn auch LF, gern verzichten.

[B.Hauser]

Noch eines ist mir jetzt nicht klar (wir haben noch V5R3 im Einsatz):
ein %Found(), %Equal() etc. bezieht sich, da ohne Datei- Angabe, m.E. doch stets auf die letzte Operation, die einen solchen Wert verändern kann und damit auf die letzte betroffene File, oder? Siehe Beispiel von Herrn Fürchau + Antwort von Frau Hauser---

Richtig! Deshalb sollte man bei allen diesen Built-In-Funktionen immer den Datei-Namen mit angeben (sofern möglich). Wäre z.B. zwischen dem SETGT und dem READE in Baldur's Beispiel noch ein Statement z.B. mit OPCode LOOKUP oder SCAN, würde nach dem READE das Ergebnis von %Found der durch diesen OpCode gesetzte Wert sein. Wäre %Found(DateiName) angegeben, würde der Wert, der durch den SETGT (letzte Aktion auf die Datei, die den Schalter %Found gesetzt hat) verarbeitet werden.

Intern wird %Found als Feldgruppe/Array geführt. Wird eine Datei angegeben, wird das entsprechende Element rausgesucht. Wird keine Datei angegeben, wird der zuletzt gesetzte Wert ausgegeben.

Birgitta

[Pikachu]

%EQUAL läßt sich nur auf SETLL und LOOKUP anwenden, jedoch leider nicht auf SETGT.

[Fuerchau]

Man darf sich doch auch mal vertun.
Natürlich meinte ich %eof().

Da ich den Status meist direkt nach der Operation benötige trage ich auch den Dateinamen nicht ein (da SEU noch kein IntelliSense unterstützt ).

Brauche ich den Status später noch einmal, weise ich ihn einer Variablen "MyFileStat = %eof();" zu, da ich ja nicht immer sicher sein kann, ob ich nicht durch eine weitere Dateioperation diesen schon wieder verändert habe.

Übrigens verwende ich häufiger
setll (K1:K2:*hival) Myfile;
als setgt, so dass mir %equal auch nicht hilft.
Das Abfragen spare ich mir da grundsätzlich.
Wenn ich mit Mandantensoftware arbeite, ist der Status selten ausreichend, ich benötige den reade/readpe auf jeden Fall.

Um die Existenz, ohne tatsächliches Lesen zu prüfen, gehe ich in SQL den Weg:
exec sql select count(*) into : MyCount
from MyFile where ....;
if MyCount>*zero;
:
endif;

[B.Hauser]

... ich könnte jetzt sagen, das war doch schon immer so (auch unter RPGIII)!

Bei RPGIII konnten bei SETLL die Hoch- (Pos.71-72) und die Gleich-(Pos.75-76) Bezugszahl gesetzt werden.

Die Hoch-Bezugszahl ging an, wenn ein folgender Read erfolgreich wäre, was aber nicht heißt, dass es (mindestens) einen Satz mit den entsprechenden Schlüssel-Feldern gibt (was %Found()) entspricht.

Die Gleich-Bezugszahl ging an, wenn ein Chain mit dem gleichen Schlüssel erfolgreich gewesen wäre (was %EQUAL()) entspricht.

Dadurch kann es sein, dass %FOUND() angeht, während %EQUAL() *OFF zurückliefert, was von vielen auch hochkarätigen Schulungsleitern als Bug angeprangert wird. (Obwohl sich zu RPGIII nichts geändert hat.)

Bei SETGT konnte schon immer nur die Hoch-Bezugszahl gesetzt werden, d.h. diese Bezugszahl ging an wenn ein folgener READP erfolgreich wäre (was %Found() entspricht) . Da man beim SETGT eigentlich davon ausgeht, dass man zumindest im letzten Schlüssel-Feld den Maximal-Wert (*HiVal) angibt, damit sicher nach dem letzten Satz positioniert wird, macht die Abfrage nach einem genauen Treffer auch wenig Sinn!

[rscheppe]

...immer wieder interessant, das Forum.
Ich frage mich, warum man beim SETGT nicht einfachheitshalber ohne den *HIVAL im letzten Teilschlüssel auskommen sollte??
Wenn ich mit SETGT arbeite, lasse ich diesen stets weg und wenn ich dann READPE wieder mit diesem Teil-Key mache und mit %EOF abfrage (letzteres habe ich gerade von Euch gelernt - danke nochmals), habe ich doch mein Ergebnis!
Oder setzt bei mir mal wieder die Logik aus?

[Fuerchau]

In diesem Fall gilt *HIVAL als Default.
Klar kannst du diesen weglassen, aber zur Programm-Dokumentation doch ganz hilfreich.