Datensatzfortschreibung in falscher Reihenfolge

[M.Heger]

Horrido!

Habe hier mal ein interessantes Problem und hoffe, dass jemand eine Idee hat ...

Ich habe vier Dateien A, B, C und D, die laut Quelle in einer bestimmten Reihenfolge mit einem RPGLE-Programm fortgeschrieben werden:

Datei A (96 Sätze)
Datei B (2 Sätze)
Datei C (3 Sätze)
Datei D (1 Satz)

Interessanterweise sieht danach die Fortschreibung im Journal folgendermaßen aus:

90 Datensätze in Datei A wurden unverzüglich fortgeschrieben.
1 Datensatz in Datei D wurde unverzüglich fortgeschrieben.

Erst bei Programmende wurde der Rest in folgender Reihenfolge fortgeschrieben:

Datei C (3 Sätze)
Datei A (6 Sätze)
Datei B (2 Sätze)

Kann mir irgendjemand einen Tipp geben?

Gruß
Michael

[Fuerchau]

Die Datei wird O-Eröffnet und intern geblockt so dass erst bei vollem Block oder Close (Programmende) tatsächlich geschrieben wird.
D.h. aber, dass das Programm nicht unter Commitsteuerung läuft, denn da wird Blockung unterbunden.
Das Risiko hier besteht, dass sogar Datenverlust auftreten kann wenn das Programm nämlich abstürzt oder der Job gekillt wird, werden Daten im internen Puffer verworfen.
Mehrere Möglichkeiten der Kompensation:
Beim Umwandeln per Option das Blocken verhindern, per FEOD(N) das Schreiben erzwingen, die Tabelle als UF eröffnen (bei ILE kein Problem, bei OPM die fehlenden Anweisungen in einer blinden BEGSR definieren).

[TheDevil]

Hallo.
Kann jetzt nur vermuten das hier die "Blockfunktion" für Datei A zuschlägt und Datei D vielleich im PGM ein Open und Close erhällt. Oder D hat in der phy. Definition ein sofortiges Schreiben (*FRCRATIO = 1).
Gruß,
Ralf

[M.Heger]

Die Datei wird O-Eröffnet und intern geblockt so dass erst bei vollem Block oder Close (Programmende) tatsächlich geschrieben wird.
D.h. aber, dass das Programm nicht unter Commitsteuerung läuft, denn da wird Blockung unterbunden.
Das Risiko hier besteht, dass sogar Datenverlust auftreten kann wenn das Programm nämlich abstürzt oder der Job gekillt wird, werden Daten im internen Puffer verworfen.
Mehrere Möglichkeiten der Kompensation:
Beim Umwandeln per Option das Blocken verhindern, per FEOD(N) das Schreiben erzwingen, die Tabelle als UF eröffnen (bei ILE kein Problem, bei OPM die fehlenden Anweisungen in einer blinden BEGSR definieren).

@Fuerchau:
Danke, das war es. Mal eben schnell aus den Nur-Ausgabe-Dateien
vollprozuderale Update-Dateien definiert, schon funktioniert es.

War das schon immer so mit den Nur-Ausgabe-Dateien, dass diese blockweise fortgeschrieben worden sind? Bin jetzt fast zwanzig Jahre dabei, ist mir aber noch nie aufgefallen ...

Gruß
Michael

[Fuerchau]

Ja, das war schon immer so wenn man das Blocken nicht explizit abschaltet.
FRCRATIO(1) auf Dateiebene ist zwar auch eine Lösung, verlangsamt aber die Schreiboperation ggf. um Faktor 1000 oder mehr.
Wenn du mit Commitsteuerung arbeitest kann auch nicht geblockt werden, da sonst ein Rollback nicht funktionieren würde. Da du ja mit Journal arbeitest empfielt sich hier doch Commitsteuerung von selber.

[hel400]

War das schon immer so mit den Nur-Ausgabe-Dateien, dass diese blockweise fortgeschrieben worden sind? Bin jetzt fast zwanzig Jahre dabei, ist mir aber noch nie aufgefallen ...

Noch als Zusatzinfo:
In der RPG-Umwandlungsliste wird sogar extra darauf hingewiesen! (ganz am Ende in der Meldungszusammenfassung).
Daher - was ich immer sage - ist es nicht schlecht, auch mal bei fehlerfreien Umwandlungen einen Blick an's Ende der Umwandlungsliste zu machen :-)

[M.Heger]

Man lernt nie aus ... ;-)

[Fuerchau]

Seit die AS/400 durch Internpufferung so schell geworden ist, lohnt die interne Blockung überhaupt nicht mehr. Reine O-Bestimmungen (außer Printer) kann man inzwischen locker vermeiden und das Problem generell verhindern.
Wie oben geschrieben, einfach als UF behandeln.

[fpxx]

Ich glaube es reicht sogar IF mit ADD.

Hat den Vorteil, dass man beim Suchen nach Programmen mit Update-Verwendung (nach einem DSPPGMREF) solche Programme nicht mitgeteilt bekommt.