Fehler beim READ

[Steven]

hoi *all

mein Problem ist schnell erklärt. Mein Programm (RPGLE) hängt sich bei einem einfachen READ auf ein PF auf. Ich habe es mit CHAIN, READE und READ probiert. Immer das gleiche. Das PF mit Datensätzen gefüllt, also dran kanns nicht liegen. Der READ ist auch nicht in einer DO-Schleife.
Ich kann mir die Ursache nicht erklären.

Wisst ihr was die Ursache für einen solchen Fehler sein kann?

[RobertMack]

Hallo Steven,

was meinst Du mit "aufhängen", wie sehen PF und F-Zeilen des RPG's aus?

Fragend, grüßend,

Robert

[Steven]

Hallo Robert,

sobald der READ kommt ist unten das X - System, also das System arbeitet. Dann geht aber nix mehr weiter. Ich kann nur noch per Systembefehl 2 beenden. Wenn ich eine Zeit lang nichts mache kommt: E/A Fehler erkannt.

Die F-Bestimmung für díe PF(SAVEERG):

FSAVEERG UF A E K DISK


[Dieser Beitrag wurde von Steven am 29. Januar 2003 editiert.]

[RobertMack]

Hi Steven,

Du hast die Datei UF definiert, das riecht nach einem RCDLCK. Prüfe mal, ob ein vorheriger READ oder ein anderes Programm den Satz blockiert.
Möglichkeiten: Nach einem Read ohne Update den Satz mit SETGT freigeben, oder, wenn kein Update beabsichtigt ist, die Datei IF definieren oder mit READ(N) lesen.

Falls Du nicht weiterkommst, müsste ich mir mal die ganze SRC ansehen...

Viel Erfolg, Robert

[Steven]

Danke. Es funzt jetzt wenn ich nach jedem READ ein SETGT mach. Aber warum eigentlich? Ich hab nämlich auch vor jedem READ ein SETLL gemacht. Da dürften doch keine Sätze blockiert sein.

[RobertMack]

... sobald eine Datei als UF geöffnet wird, bedeutet jeder Satzzugriff eine Sperre! Diese wird nur durch einen Update, Unlock oder eben durch eine Neupositionierung des Zeigers (SETxx) aufgehoben.

Gruß Robert

[Fuerchau]

Ich würde auf jeden Fall den Tipp von Robert annehmen und einen "read(n)" nehmen. Das spart vor allem unnötige Zugriffe und das Programm läuft schneller, z.B.:

kyFile setll myfile
do *hival
kyfile reade(n) myfile
if %eof(myfile) then
leave
endif
:
:
enddo

[B.Hauser]

Man sollte vielleicht noch anmerken, dass die ganze Geschichte mit Unlock bzw. (N)-Erweiterung und SETGT nicht funktionniert, wenn mit Commitment Control gearbeitet wird.

Bei der Commitment Control bleibt ein Satz bis zum nächsten Commit gesperrt. Auch über mehrere Programme hinweg, und wenn das Programm mit *INLR beendet wurde.

Birgitta

[Fuerchau]

das hängt aber ganz von der verwendeten Commit-Methode ab.
Standard ist *CHG und dann werden ausschließlich geänderte Sätze bis zum Commit gesperrt.
Das reine Lesen, selbst mit Sperre und anschließendem Weiterlesen mit Sperre hebt die vorherige Sperre wieder auf.

Das Lesen ohne Sperre durch andere Programme wird übrigens nicht verhindert, wenn dann mal ein Rollback durchgeführt wird, ist der Satz im anderen programm nicht mehr gültig.