Embedded SQL in Modul - Nach Insert bleibt Datei gesperrt (*EXCL)

[JonnyRico]

Hi,

ich führe von meinem Hauptprogramm ein NoMain-Modul aus das ein Insert auf eine Datei macht. Muss diese danach explizit geschlossen werden und wenn wie?
Nachdem das Modul durch ist und dann auch das Hauptprogramm beendet ist, ist die Datei immer noch gesperrt und steht auf *EXCLRD bzw. *EXCL
Hat jemand einen Tip für mich?

Gruß

Sascha

[BenderD]

Hallo Sascha,

Wenn du nicht isolation level serializable hast, dann ist das ein Bug. Grundsätzlich gilt, dass commit record locks und die table locks von serializable freigibt. Ansonsten werden SQL locks erst beim disconnect, bzw. endjob sicher freigegeben.

mfg

Dieter Bender

Hi,

ich führe von meinem Hauptprogramm ein NoMain-Modul aus das ein Insert auf eine Datei macht. Muss diese danach explizit geschlossen werden und wenn wie?
Nachdem das Modul durch ist und dann auch das Hauptprogramm beendet ist, ist die Datei immer noch gesperrt und steht auf *EXCLRD bzw. *EXCL
Hat jemand einen Tip für mich?

Gruß

Sascha

[JonnyRico]

Hallo Sascha,

Wenn du nicht isolation level serializable hast, dann ist das ein Bug.

Okay...sorry aber was genau ist isolation level serializable?
Okay das das mit dem End Job habe ich schon getestet. Könnte das ganze ja also per SBMJOB übergeben und dann passt es. Allerdings würde mich das doch sehr interessieren wie ich das auch Interaktiv hin bekomme das wenn mein Programm beendet wird, die Sperren weg sind. Ich habe eben schon mal "C+ Disconnect Current" versucht. Leider ohne Erfolg. Kannst du mir das vielleicht erklären. Schon mal vielen Dank.

Gruß

Sascha

[BenderD]

Hallo Sascha,

beim CRTSQLRPGI gibt es einen Parameter Commit, der steht im default auf *CHG, diesen Wert kann man im Programm noch mit set option oder set transaction isolation überschreiben; da gibt es auch einen Wert *RR, was man im SQL Standard serializable nennt.
Wenn du weder hier noch da gebastelt hast, dann ist eure Datenbank kaputt, sprich Group PTF Database bestellen und einbauen.
Falls du doch dran gedreht hast, dann fehlt dir ein Commit; der ENDJOB gibt dann zwar die Sperren frei, aber macht implizit einen Rollback, sprich deine Sätze sind fort.

mfg

Dieter Bender

Okay...sorry aber was genau ist isolation level serializable?
Okay das das mit dem End Job habe ich schon getestet. Könnte das ganze ja also per SBMJOB übergeben und dann passt es. Allerdings würde mich das doch sehr interessieren wie ich das auch Interaktiv hin bekomme das wenn mein Programm beendet wird, die Sperren weg sind. Ich habe eben schon mal "C+ Disconnect Current" versucht. Leider ohne Erfolg. Kannst du mir das vielleicht erklären. Schon mal vielen Dank.

Gruß

Sascha

[JonnyRico]

Naja also ich mache vor dem "Insert...." einmal

C/Exec SQL Set Option Commit=*None 

Ist das vielleicht das Problem? Allerdings kann ich sonst nicht schreiben da die Datenbank nicht im Journal aufgezeichnet wird.

---

Wenn ich das Programm per SBMJOB starte sind die Daten nach Beendigung so wie gewünscht in den Datenbanken und die Sperren sind weg.

[BenderD]

Hallo Sascha,

set option ist eine Compile Time Anweisung und bewirkt bei dir dasselbe, wie wenn man beim CRTSQLRPGI COMMIT *NONE angibt. wenn die Datei nicht unter Journal ist, dann kannst du nur Commit *NONE nehmen und dann sind Dateisperren *EXCL und *EXCLRD eindeutig ein Bug. Fehlermeldung an IBM Group PTFs für die Datenbank einspielen.

mfg

Dieter Bender

Naja also ich mache vor dem "Insert...." einmal

C/Exec SQL Set Option Commit=*None 

Ist das vielleicht das Problem? Allerdings kann ich sonst nicht schreiben da die Datenbank nicht im Journal aufgezeichnet wird.

---

Wenn ich das Programm per SBMJOB starte sind die Daten nach Beendigung so wie gewünscht in den Datenbanken und die Sperren sind weg.

[JonnyRico]

Na okay. Danke Dieter. Ich denke ich werde mich dann doch morgen dem Problem noch mal im Detail widmen und mich dann an Big Blue wenden.
Danke schönen Feierabend.

Gruß

Sascha

[Fuerchau]

Naja, ganz so ist es leider nicht.
SQL hält einen Insert-Cursor automatisch geöffnet (ODP), da ja noch ein 2. Insert folgen könnte und somit SQL diverse Routinen (Open, Prepare, Field- und Type-Check usw.) spart.
Das ist auch kein Bug (@Dieter) sondern vom Optimizer so gewollt.
Es gibt noch die Option, wann ein Cursor geschlossen werden soll:

set option closqlcsr=*endmod

Wenn das Modul beendet ist, werden alle SQL-Statements freigegeben und ODP's geschlossen (Default = *endjob):

CLOSQLCSR
Specifies when SQL cursors are implicitly closed, SQL prepared statements are implicitly discarded,
and LOCK TABLE locks are released. SQL cursors are explicitly closed when you issue the CLOSE,
COMMIT, or ROLLBACK (without HOLD) SQL statements. This option will be ignored in REXX.
*ENDACTGRP and *ENDMOD are for use by ILE programs and modules. *ENDPGM, *ENDSQL, and
*ENDJOB are for use by non-ILE programs.
This option is not allowed in an SQL function, SQL procedure, or SQL trigger.
*ENDACTGRP
SQL cursors are closed, SQL prepared statements are implicitly discarded, and LOCK TABLE
locks are released when the activation group ends.
*ENDMOD
SQL cursors are closed and SQL prepared statements are implicitly discarded when the module is
exited. LOCK TABLE locks are released when the first SQL program on the call stack ends.
*ENDPGM
SQL cursors are closed and SQL prepared statements are discarded when the program ends.
LOCK TABLE locks are released when the first SQL program on the call stack ends.
*ENDSQL
SQL cursors remain open between calls and can be fetched without running another SQL OPEN.
One of the programs higher on the call stack must have run at least one SQL statement. SQL
cursors are closed, SQL prepared statements are discarded, and LOCK TABLE locks are released
when the first SQL program on the call stack ends. If *ENDSQL is specified for a program that is
the first SQL program called (the first SQL program on the call stack), the program is treated as if
*ENDPGM was specified.
*ENDJOB
SQL cursors remain open between calls and can be fetched without running another SQL OPEN.
The programs higher on the call stack do not need to have run SQL statements. SQL cursors are
left open, SQL prepared statements are preserved, and LOCK TABLE locks are held when the first
SQL program on the call stack ends. SQL cursors are closed, SQL prepared statements are
discarded, and LOCK TABLE locks are released when the job ends.

[BenderD]

@Baldur:
im Eingangsposting stand:
Datei immer noch gesperrt und steht auf *EXCLRD bzw. *EXCL
und das ist m. E. keine Folge eines offenen Cursors und auf das EXCLRD bzw. EXCL bezieht sich die Bezeichnung Bug.

@All:
Cursor gehören bei sauberer Programmierung immer mit CLOSE cursorname geschlossen; bzw. noch einfacher ist es mit Commitment Controll, da schließt ein Commit (ohne hold, versteht sich) alle offenen Ressourcen.

Zum Close ist allgemein noch zu ergänzen: jeder close in SQL ist ein lazy close, d.h. die SQL Engine wird den ODP im allgemeinen offen halten!!!

Die Einstellung CLOSSQLCSR sorgt lediglich dafür, dass eine SQL close Operation auf den Cursor gemacht wird, garantiert aber keineswegs ein schließen des ODP.

Zu set option ist noch zu ergänzen: das ist eine Compiletime Anweisung, die immer nur für das erste SQL Programm/SRVPgm der Activation Group Auswirkungen hat (nebenbei bemerkt: fast unübersehbar, was zuerst aktiviert wird!!!).

Tatsächlich sicher freigegeben werden die SQL Ressourcen beim ENDJOB und bei OPM/ILE Programmen, die per SQL auf die lokale Datenbank zugreifen beim disconnect; bei Cleint Server Programmen nicht einmal dann. Wenn das stört, weil zum Beispiel ein anderes Programm ein RGZPFM, oder ähnliches machen will (sowas soll es ja auch noch geben), dann kann man mit ALCOBJ CONFLICT(*RQSRLS) von aussen die Freigabe einleiten.

mfg

Dieter Bender

Naja, ganz so ist es leider nicht.
SQL hält einen Insert-Cursor automatisch geöffnet (ODP), da ja noch ein 2. Insert folgen könnte und somit SQL diverse Routinen (Open, Prepare, Field- und Type-Check usw.) spart.
Das ist auch kein Bug (@Dieter) sondern vom Optimizer so gewollt.
Es gibt noch die Option, wann ein Cursor geschlossen werden soll:

set option closqlcsr=*endmod

Wenn das Modul beendet ist, werden alle SQL-Statements freigegeben und ODP's geschlossen (Default = *endjob):

CLOSQLCSR
Specifies when SQL cursors are implicitly closed, SQL prepared statements are implicitly discarded,
and LOCK TABLE locks are released. SQL cursors are explicitly closed when you issue the CLOSE,
COMMIT, or ROLLBACK (without HOLD) SQL statements. This option will be ignored in REXX.
*ENDACTGRP and *ENDMOD are for use by ILE programs and modules. *ENDPGM, *ENDSQL, and
*ENDJOB are for use by non-ILE programs.
This option is not allowed in an SQL function, SQL procedure, or SQL trigger.
*ENDACTGRP
SQL cursors are closed, SQL prepared statements are implicitly discarded, and LOCK TABLE
locks are released when the activation group ends.
*ENDMOD
SQL cursors are closed and SQL prepared statements are implicitly discarded when the module is
exited. LOCK TABLE locks are released when the first SQL program on the call stack ends.
*ENDPGM
SQL cursors are closed and SQL prepared statements are discarded when the program ends.
LOCK TABLE locks are released when the first SQL program on the call stack ends.
*ENDSQL
SQL cursors remain open between calls and can be fetched without running another SQL OPEN.
One of the programs higher on the call stack must have run at least one SQL statement. SQL
cursors are closed, SQL prepared statements are discarded, and LOCK TABLE locks are released
when the first SQL program on the call stack ends. If *ENDSQL is specified for a program that is
the first SQL program called (the first SQL program on the call stack), the program is treated as if
*ENDPGM was specified.
*ENDJOB
SQL cursors remain open between calls and can be fetched without running another SQL OPEN.
The programs higher on the call stack do not need to have run SQL statements. SQL cursors are
left open, SQL prepared statements are preserved, and LOCK TABLE locks are held when the first
SQL program on the call stack ends. SQL cursors are closed, SQL prepared statements are
discarded, and LOCK TABLE locks are released when the job ends.

[Fuerchau]

Nur, dass ein Insert-Cursor nicht explizit geschlossen werden kann (es gibt ja keinen Namen dafür).
Durch das closqlcsr=*endmod werden ja auch die Statements (hier das Insert-Statement) beim Verlassen freigegeben und somit der ODP geschlossen (jedenfalls bei meinen Test's).
Ganz sicher geht's mit einer benannten Actgrp, die nach Beenden per RCLACTGRP definitiv aufgelöst wird und auch die (automatische) DB-Anmeldung aufgehoben wird.

[BenderD]

@Baldur:
ein offener ODP wg. eines Inserts verursacht aber keine Sperren, die weh tun, maximal shrxxx für die Datei und record locks gibt es ohne commitment controll hier auch keine.
Und Vorsicht: der CLOSQLCSR ist nur ein impliziter close und garantiert genausowenig wie ein expliziter close (der hier nicht geht) einen close des ODP und eine Aufgabe der zugehörigen Sperre.
Ob der RCLACTGRP die Sperren aufgibt, habe ich nicht im Kopf, aber der geht hier auch nicht, weil das NOMAIN dann ja aus einer anderen ACTGRP aufgerufen wird und dann in den Wald rennt, da das aufrufende Programm nicht neu aktivieren kann (es sei denn, man bindet selber zur Laufzeit), da würde hier new helfen, aber das ist auch Schmonz.
Aber: EXCL Sperre ohne serializable ist und bleibt Bug!

mfg

Dieter

Nur, dass ein Insert-Cursor nicht explizit geschlossen werden kann (es gibt ja keinen Namen dafür).
Durch das closqlcsr=*endmod werden ja auch die Statements (hier das Insert-Statement) beim Verlassen freigegeben und somit der ODP geschlossen (jedenfalls bei meinen Test's).
Ganz sicher geht's mit einer benannten Actgrp, die nach Beenden per RCLACTGRP definitiv aufgelöst wird und auch die (automatische) DB-Anmeldung aufgehoben wird.

[Fuerchau]

Vielleicht ist ja SQL gar nicht die Ursache. Beim Insert wird die Datei auch gar nicht mit *EXCL bzw *EXCLRD gesperrt, sondern, wie du schon korrekt sagst nur mit SHRRD.

Vielleicht wird die Datei ja irgendwie per ALCOBJ gesperrt und nur der DLCOBJ vergessen ?
Leider ist ja der Default-Scope = *JOB !!!