Teildatei- Satzsperren bei SQLRPGLE obwohl Programm zu

[andreaspr@aon.at]

bei einem SQLRPGLE habe ich folgendes Phänomen, das auf einer Datei Satz und Teildateisperren bleiben, obwohl das Programm beendet ist.

Hallo,
das klingt für mich nach Commitment-Control. Falls es so ist, entweder vor Programmende ein

Exec Sql Commit;

oder

Exec Sql set options Commit=*none;

[Pikachu]

Wird das Programm mit LR auf ON beendet?

[B.Hauser]

Wird das Programm mit LR auf ON beendet?

*INLR=*ON betrifft nur den RPG-Zyklus und nicht embedded SQL.
... und unter ILE funktioniert der *INLR anders als unter RPGIII, zwar werden die Dateien, die in den F-Bestimmungen definiert sind nach wie vor geöffnet und geschlossen, das Programm wird jedoch nicht aus dem Speicher entfernt. Beim nächsten Aufruf wird lediglich der (noch) reservierte Speicher neu initialisiert.
Ein Programm wird erst durch Beenden der Aktivierungsgruppe in der es läuft aus dem Speicher entfernt.

P.S. RPG-Zyklus meint nicht zwingend IP, sondern dass der Zyklus in jeder RPG-Main-Procedure automatisch aktiviert ist.

Birgitta

[Dschainers]

Programm umwandeln mit COMMIT(*NONE)

[Dschainers]

Programm umwandeln mit COMMIT(*NONE)

[ExAzubi]

Ich habe jetzt mal die SET OPTION CLOSECSR = ENDMOD gesetzt und zumindest die Satzsperren sind verschwunden, jetzt blieben nur noch die Teildateien geöffnet. Alles sehr merkwürdig.

Eine Frage zur Aktivierungsgruppe, wenn ich mit Aktivierungsgruppe *NEW das Programm wandel, wird dann nicht automatisch auch beim Programmende die Aktivierungsgruppe geschlossen?

[BenderD]

... nochmal: die database engine betreibt einiges an caching - und das ist auch gut so!!! Was stört dich konkret an dem Verhalten???

D*B

Ich habe jetzt mal die SET OPTION CLOSECSR = ENDMOD gesetzt und zumindest die Satzsperren sind verschwunden, jetzt blieben nur noch die Teildateien geöffnet. Alles sehr merkwürdig.

Eine Frage zur Aktivierungsgruppe, wenn ich mit Aktivierungsgruppe *NEW das Programm wandel, wird dann nicht automatisch auch beim Programmende die Aktivierungsgruppe geschlossen?

[ExAzubi]

Eigentlich nichts, nur in diesem konkreten Beispiel ist es, das sich bei den Dateien um "Arbeitsdateien" handelt, wenn jetzt ein weiterer User das Programm aufruft, dann klappt ggf. der CLRPFM nicht da die Datei noch offen ist.

Ich werde es so machen, das ich die Objekte als Batchjob in die QTEMP kopiere dort wird dann geackert, und später kopiere ich die Dateien dann wieder zurück.

[andreaspr@aon.at]

... nochmal: die database engine betreibt einiges an caching - und das ist auch gut so!!!

Sicher? Soviel ich weis wird die Aktivierungsgruppe *NEW automatisch vom System bereinigt, sobald das Programm beendet wird. Selbst wenn z.B. noch ein Commit offen ist.

[B.Hauser]

Sicher? Soviel ich weis wird die Aktivierungsgruppe *NEW automatisch vom System bereinigt, sobald das Programm beendet wird. Selbst wenn z.B. noch ein Commit offen ist.

Sie Database Engine versucht die ODPs solange offenzuhalten wie möglich. Sobald die Aktivierunggruppe geschlossen wird, werden die zugeordneten Ressourcen bereinigt. Das gilt auch für die in der Aktivierungsgruppe geöffneten ODPs. Commit oder nicht Commit hat mit den geöffneten ODPs wenig zu tun. Ein Update erfolgt immer auf die Echt-Daten und nicht Daten, die in irgendwelchen temporären Objekten gespeichet sind.

Was mich allerdings bei der ganzen Sache stört ist das Wort Teildateien:

und zumindest die Satzsperren sind verschwunden, jetzt blieben nur noch die Teildateien geöffnet.

Werden hier Overrides oder Aliases verwendet um auf echte Teildateien zuzugreifen.
Ansonsten, wenn du wirklich die Datei bereinigen willst, solltest Du die Daten mit dem SQL Delete herausfegen. Sofern keine Locks bestehen wird Under the Cover ein CLRPFM ausgeführt, ansonsten werden lediglich die Datensätze gelöscht.

Ich werde es so machen, das ich die Objekte als Batchjob in die QTEMP

Batchjob in QTEMP!!! Bist Du sicher, das das klappt???

Birgitta

[BenderD]

... immer diese Mythen:
@CLOSSQLCSR: F1 macht schlau!
Gibt an, daß SQL-Cursor implizit geschlossen, mit SQL vorbereitete
Anweisungen implizit gelöscht und Sperren, die mit LOCK TABLE
erfolgten, freigegeben werden. SQL-Cursor werden explizit
geschlossen, wenn der Benutzer die SQL-Anweisung CLOSE, COMMIT oder
ROLLBACK (ohne HOLD) ausgibt.
Schlußfolgerungen:
1.) das sind alles logische close Operationen, ob wirklich geschlossen wird, obliegt der Database Engine (kann sich also auch jederzeit ändern!)
2.) Wer mit Commit arbeitet, hat es hier einfacher!

@caching: Was die Database Engine wirklich cached, ist nicht dokumentiert und kann sich damit selbst mit einem PTF ändern. Applikationen dürfen nur auf dokumentierte Eigenschaften vertrauen, alles andere ist ein klassischer Kunstfehler.
Schlussfolgerungen:
1.) Wer alles mit SQL macht, hat mit den vom OP angesprochenen Sperren kein Problem.
2.) Wer Mix mit Altlasten hat, muss bei den Altlasten ansetzen. Der korrekte Weg dazu ist vor CLRPFM, RGZPFM und ähnlichem einen ALCOBJ CONFLICT(*RQSRLS) abzusetzen.

D*B