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

[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 !!!

[JonnyRico]

Stimmt am Insert wie gestern vermutet liegt es nicht. Das Problem titt in einem anderen Modul auf. Vor dem Insert werden einige Dateien in einem anderen Modul per
Delete from ParmLib/ParmTbl gelöscht.
Hier wird dann die Sperre gesetzt die bis zum Programmende nicht abgegeben wird und erst beim ENDJOB wieder verschwindet.
Die zu löschenden Tabellen werden per Parameter übergeben und werden dann in einer Schleife in der Modul geleert.

Do
.
.
Prepare DELSTAT
.
.
Execute DELSTAT
.
.
Enddo

[Fuerchau]

Auch diese Sperre muss ausserhalb von SQL gesetzt sein, da auch der Delete wie der Insert keine EXCL-Sperre setzt.