Fehlerbehandlung im RPGLE-FREE

[kretzsch]

Guten Tag Forum,>>
Ich hatte gestern wahrscheinlich etwas falsch gemacht, da ich meine Anfrage nicht sehen kann und auch keine Reaktion per mail erhalten habe. Hie noch einmal mein Problem.>>
>>
In einem interaktiven Programm wird eine log.File zunächst eingelesen zum Aktualiesieren in Abhängigkeit einer anderen Datei. Dann kann jeder einzelne Satz bearbeitet werden. Wird das Programm von mehreren Anwendern genutzt, gibt es das Problem der Sperren, wenn ein Satz gerade benutzt wird. Ich wollte dies mit einer Monitorgruppe abfangen. >>
>>
Aktualiesierung:>>
monitor; >>
read dateir;>>
on-error 1218;>>
#err = *on;>>
Endmon; >>
>>
Dow not %eof(datei);>>
If #err *off; >>
>>
Aktualisierung>>
> >
Endif;>>
> >
Nächsten Satz einlesen>>
monitor; >>
read dateir;>>
on-error 1218;>>
#err = *on;>>
Endmon; >>
>>
Enddo;>>
>>
Jetzt folgt die Verarbeitung: -> Subfile füllen -> Satz auswählen und updaten>>
>>
Jetzt mein Problem: Es kommt zwar nicht zum Fehler aber das Programm liest nicht den nächsten Satz sondern immer wieder den gesperrten Satz. Wie kann ich die on-error Lösung besser gestalten? Ich möchte nicht mit read(n) einlesen.
Vielen Dank für eure Hilfe
kretzsch

[Fuerchau]

Mit Read(e) benötigt man keinen Monitor. %error() liefert dann den Status.
Leider kann man ohne Read(n) gesperrte Sätze nicht überlesen.
Im Falle der Sperre musst du selber per Read(n) den gesperrten Satz dann überlesen.

[kretzsch]

Schade, schade ... aber trotzdem danke.

[Fuerchau]

Du musst deine Logik überarbeiten.
Zum Anzeigen aller Sätze per READ(N) die Subfile füllen.
Zum Bearbeiten eines Satzes dann per CHAIN genau diesen Satz dann sperren.

[kretzsch]

Genau so hatte ich es auch immer gemacht, ich dachte man kann es mit dem Befehl Monitor eleganter lösen.

[AG1965_2]

Das wäre aber ein Drama, wenn sich der Lesebefehl je nach Fehlerüberwachung anders verhielte!
Aber es passiert logischerweise das absolut Idente, der Lesebefehl kann nicht lesen. Ob man diesen Zustand nun per Bezugszahl, Built-In-Funktion oder MONITOR feststellt, darf für die Position des Dateizeigers keinen Unterschied machen.
Außerdem sollte man DB-Sätze nur dann sperren, wenn die Updatewahrscheinlichkeit hoch ist.
Zum Füllen eines Subfiles aber auf keinen Fall, wie Baldur schon völlig richtig angemerkt hat.
Und selbst wenn es ginge; die Faulheit beim Codieren würde sich da sowieso zur Laufzeit rächen. Man muss nur genug User drauf los lassen.

[camouflage]

Außerdem sollte man DB-Sätze nur dann sperren, wenn die Updatewahrscheinlichkeit hoch ist.
Und selbst wenn es ginge; die Faulheit beim Codieren würde sich da sowieso zur Laufzeit rächen. Man muss nur genug User drauf los lassen.

Genau aus diesem Grund verwende ich zum lesen eine logische Inputdatei und eine Updatedatei.
Und schon sind einige Probleme gelöst.

[AG1965_2]

Halte ich auch für übertrieben, nur deswegen 2 Datenpfade zu öffnen, wo es doch READ(N) usw. gibt, womit ich auch eine Datei, die für Update geöffnet wurde, ohne Sperre lesen kann.

[Fuerchau]

Die Satzwartezeit (Default 1 Minute) ist dann auch nicht zu verachten.
Warum soll man den User erst 1 Minute warten lassen um dann unvollständige Daten anzuzeigen?
Bei SQL und Transaktionen muss ja sowieso anders denken.

[kretzsch]

Für mein Verständnis sehr hilfreich, danke

[B.Hauser]

Halte ich auch für übertrieben, nur deswegen 2 Datenpfade zu öffnen, wo es doch READ(N) usw. gibt, womit ich auch eine Datei, die für Update geöffnet wurde, ohne Sperre lesen kann.

Das klappt aber nur wenn Du ohne Commitment Control arbeitest.
Unter Commitment Control gibt weder die Erweiterung (N) noch der OpCode UNLOCK den Datensatz frei!

Birgitta

[AG1965_2]

Danke Birgitta, wieder was (von dir) gelernt!