Exception Handling bei Satzsperre in SQLRPGLE

[Albrecht_Ch]

Hallo,

ich habe mal eine etwas ungewöhnliche Frage. Hierzu muss ich jetzt mit der Erklärung etwas ausholen:

Bei den Std. RPG File-Zugriffsmethoden (z.B. CHAIN) bekomme ich ja einen Fehler, wenn ich auf einen bereits gesperrten Satz versuche zuzugreifen. Diese Fehlermeldung kann ich über die PSDS (Program Status Data Structure) an Stelle 91 bis 170. Hier steht dann zum Beispiel "Satz 36 wird von Job 178679/xxx/yyy benutzt." (xxx = Benutzer yyy = Sitzung). Diese Meldung und die interne Telefonnummer des Benutzers (welcher den Satz sperrt) gebe ich dann als Fehlermeldung dem anderen Benutzer (wo versucht auf den Satz zuzugreifen) aus. Soviel zur schönen Classic-RPG-Welt.

Jetzt habe ich ein SQLRPGLE Programm wo ich über SQL - Abfragen auf Sätze in Dateien zugreife und später update. Hierzu habe ich einen DYNAMIC SCROLL CURSOR declariert. Wenn ich nun mit FETCH einen Bereits gesperrten Satz versuche zu lesen, bekomme ich den SQLCODE -913 (Satzsperre). Soweit so gut ... jedoch ist die SDSMSG (PSDS Stelle 91 bis 170) leer . Somit scheint an dieser Stelle für die PSDS keine exception oder error vorzuliegen . Jedoch im JobLog steht an dieser Stelle meine ersehnte Fehlermeldung.

Gibt es eine Möglichkeit, dass sich die PSDS auch bei SQL-Zugriffsfehlern füllt?

Oder mach ich da nur etwas falsch?

Vorab schon mal vielen Dank!

[Fuerchau]

SQL kennt die SDS gar nicht.
Wenn du dir aber die Spoolfile mal ansiehst, erkennst du eine Struktur SQLCA.
Im Feld SQLERM stehen die Daten zum SQLCOD. Ob aber SQL so ins Detail geht, wie benötigt weiß ich nicht.

[Albrecht_Ch]

Diese Antwort habe ich schon fast befürchtet . Die Informationen in der Struktur SQLCA sind leider nicht so aussagekräftig. Es steht in der SQLERM eigentlich nur die Lib und die Datei.

Für mich wichtig wäre der User wo den Satz gerade im zugriff hat.

Trotzdem vielen Dank für die Info zum SDS.

[Fuerchau]

Da hilft dir wohl leider nur ein Serviceprogramm, in dem du den normalen Zugriff auf die Datei kapselst um im Fehlerfall die Sperre abzufragen, was allerdings durch die Zeitverzögerung ggf. negativ beantwortet würde.

[andreaspr@aon.at]

Hallo Albrecht_Ch,

es gibt eine recht mächtige funktion in SQL (Get Diagnostics).
mit diesem tool, kannst du alle möglichen informationen zu deinem letzten (oder die letzten) sql-aufrufe holen.

D vsqlstt         S             512A
/Free
  Exec Sql Get Diagnostics CONDITION 1
        :vsqlstt = MESSAGE_TEXT;    
  dsply (sqlstt);                     
/End-Free

es gibt 2 sehr gute handbücher in denen du auf jedenfall genug informationen finden kannst.

hoffe es hilft dir weiter!

System i
Database
Embedded SQL programming
Version 6 Release 1
5761–SS1

IBM Systems - iSeriesDB2 for i5/OS SQL Reference Version 5 Release 4
5722–SS1

lg andi

[B.Hauser]

... nur leider gibt Get Diagnostics auch nur die Fehlermeldung, dass in der Datei eine Satz-Sperre vorliegt, aber nicht welcher Job bzw. welcher User welchen Satz blockiert.

Hier sind übrigens die Links zu den Online-Books:
SQL Reference - Release 6.1
Embedded SQL Programming - Release 6.1

Birgitta

[dabeda]

Du kannst über die API QGYOLJBL das Joblog auslesen und dir die Meldung holen die du brauchst. Leider ist das dann einfach ein ganzer Textstring ohne Variablen.

Alternativ kannst du bei einem Lock die relative Satznummer auslesen (select rrn(datei) from datei where ) und dann mit der API QDBRRCDL den Benutzer usw. auslesen. Das Ganze dann noch schön in einem Serviceprogramm verpackt und man merkt gar nicht mehr, dass SQL das eigentlich gar nicht kann. ;-)

MfG

[Fuerchau]

Wobei der Select RRN ganz schön dauert, da hier grundsätzlich kein Index verwendet wird.
Eine schnelle und vor allem gute Lösung ist das nicht.

Was ich mich allerdings frage, wieso der SELECT gesperrte Sätze nicht liest ?
Einen Fehler gibts eigentlich erst beim UPDATE/DELETE oder der gesperrte Satz wird einfach überlesen.

[dabeda]

So schnell wie im RPG ist das natürlich nicht, man kann aber beim declare cursor gleich die relative Satznummer mit auslesen, dann erspart man sich das nachher. Obwohl ich eingentlich nicht so viele Locks erwarte dass es zeitlich ein Problem wird die relative Satznummer auszulesen.
Glaube das Überlesen von gelockten Sätzen funktioniert erst bei V6.1, kann mich aber täuschen.

[Fuerchau]

Das Überlesen ist ja nicht das Problem.
Ich kann durchaus gesperrte Sätze lesen!

Allerdings darf ich den Cursor nicht als "for update" deklarieren, da im Falle des Lesens genau dann ein Sperre gesetzt wird und es ggf. zum Fehler kommt.

SQL-Like ist das nicht.
MS-Access / ADO.NET geht den "normalen" Weg, dass vor dem Update / Delete die aktuelle Information erst noch mal gelesen und mit dem vorherigen Zustand verglichen wird. Ist der Inhalt noch unverändert, wird geändert an sonsten ein Fehler ausgelöst.

Dies wäre das korrekte Anwendungsverhalten, denn eine potentielle Satzsperre ohne den tatsächlichen Wunsch einer Veränderung sollte nicht erfolgen.

[mwithake]

Wobei der Select RRN ganz schön dauert, da hier grundsätzlich kein Index verwendet wird. Eine schnelle und vor allem gute Lösung ist das nicht.

Das Stimmt nicht, Indexe werden auch zur Ermittlung von RRN() verwendet.

[Fuerchau]

Wenn du einen
select ... where rrn() = 1234
verwendest, kann SQL keinen Index verwenden, da es keinen Index über RRN gibt.
Schränkst du natürlich auf weitere Schlüssel ein, werden für diese natürlich Indizees verwendet.