View Full Version : Commit ?
Cursor (sind nur zum Lesen) haben mit ODP's nicht viel zu tun.
Cursor werden geschlossen, wobei die ODP's zur Optimierung aufbleiben können.
Da ein Cursor keine Daten ändern kann (for-update-Cursor benötigen einen Update) wüsste ich nicht, wie das Schließen einen Rollback auslösen kann.
FRCRATIO(1) ist nicht zu verwechseln mit SEQONLY(*YES/*NO).
FRCRATIO(1) hat direkte Auswirkung auf die Performance.
In simpler CPYF wird u.U. um Faktor 1000 langsamer bei eingeschaltetem FRCRATIO(1), was halt mit der Kontrolle zu tun hat, ob der Satz auf der Platte ist oder nicht.
Was die RPG-Pufferung angeht, so trifft diese nur bei I und O-Dateien zu.
Hier wird erst mal nur durch die Runtime "gepuffert" bevor die Daten an das OS abgegeben werden.
Wobei durch FRCRATIO(1) dieses wieder ausgeschaltet wird (ominöse Log-Meldung "Zugriff wurde in SEQONLY(*NO) geändert").
Ich habe in einer Altanwendung allein durch abschalten des FRCRATIO Laufzeiten von Stunden in Minuten gekürzt.
Ja sag ich doch, dass FRCRATIO die Performance beeinflusst ...
Allerdings hat das bei RPG nur Auswirkung auf "O"-Dateien, nicht aber bei "I"
(die Eingabe wird dadurch nicht beschleunigt. Das ginge (speziell bei Sequentiellem Lesen) zB durch Einschalten des Expert Cache, welcher komischerweise bei den meisten Maschinen nicht beachtet wird).
Dass durch Abschalten von FRCRATIO das Ganze schneller wird, ist daher klar (aber eben nur beim Output), das habe ich ja aber genau so beschrieben.
Stimmt, beim Lesen hat das keine Auswirkung.
FEOD hat keine nennenswert verlangsamende Wirkung.
Bei RPG-geblockten O-Dateien erzwingt dieses nur das Ausgeben des Puffers.
Somit kann man beim Return mit *INLR = OFF sicher sein, alle Daten ans OS abgegeben zu haben.
Der Write-Cache (OS/400, Platten-Puffer) wird trotzdem verwendet.
FRCRATIO führt meist dazu, dass der Blockungswunsch beim Schreiben schon beim OPEN abgelehnt wird, ein FEOD somit nichts zu tun hat.