30 Sekunden Lock-Wartezeit bei STRQMQRY erhöhen?

[schatte]

In einem CL-Programm verwende ich den Befehl STRQMQRY. Nun kann es manchen Fällen passieren, dass eine Tabelle, die im Query verwendet werden soll, zu diesem Zeitpunkt gesperrt ist (z.B. RGZPFM).
In diesem Fall habe ich folgende Einträge im Joblog:

16:12:20 SQL7982 "SET CONNECTION to relational database XYZ completed."
16:12:52 CPF4270 "Cannot allocate member MYTABLE type *FILE."
16:12:52 SQL0913 "Row or object MYTABLE in MYLIB type *FILE in use."
16:12:52 QWM1201 "RUN QUERY command failed with SQLCODE -913."
16:12:52 QWM1102 "RUN QUERY command ended due to error."
16:12:52 QWM2701 "STRQMQRY command failed."

Wie man sieht, liegen zwischen den ersten beiden Meldungen ca. 30 Sekunden, was der Default wait time (DFTWAIT) des Jobs entspricht.

Diesen Timeout Wert möchte ich gerne auf 3600 Sekunden erhöhen, sodass der Job, der STRQMQRY ausführt, solange maximal wartet, bis die Tabelle wieder verwendbar ist.

Ich habe versucht den Wert mit folgenden Parametern zu ändern, leider ohne Erfolg:

• CHGJOB DFTWAIT(3600)
• OVRDBF WAITFILE(3600) OVRSCOPE(*CALLLVL)

Zum Test habe ich in einer Session ALCOBJ OBJ((MYLIB/MYTABLE *FILE *EXCL)) ausgeführt und in einer anderen Session den STRQMQRY Befehl.

Habt ihr eine Idee, was ich falsch mache?

[Fuerchau]

Das hat mit Objektwartezeiten nichts zu tun, SQL schätzt seine Ausführungsdauer und wenn diese vorraussichtlich 30 Sekunden übersteigt, wird gar nicht erst ausgeführt.

Via ODBC gibts eine Einstellung (ODBC/JDBC) zum QUERYTIMEOUT.

Native auf der I gibts das CHGQRYA-Kommando.
https://www.ibm.com/support/pages/od...-exceeds-limit
weil die Einstellungen nach Möglichkeit nicht systemweit gehen sollten.

Allerdings solltest du deinen SQL mit ACS und Explain prüfen, wo die Fehleinschätzungen bzw. die Ursachen zu suchen sind. I.d.R. ist das die Nichtverwendung von bestehenden Indizes, was durchaus durch fehlende Angaben von Join .. on oder where-Klauseln bedingt ist.
Auch u.U. falsche Typisierung (z.B. char vs zoned) verhindert durchaus die Indexnutzung.

Eins der häufigsten Probleme ist z.B. bei mandantfähiger Software den Mandantschlüssel weg zu lassen, obwohl gerade dieser meist an 1. Stelle des Keys steht.

[B.Hauser]

Bist Du Dir sicher, dass es die Job-Wartezeit ist?
Ich würde ehrer sagen es ist die Datei-Wartezeit und/oder die Satz-Wartezeit.
Versuch' mal über OVRDBF die Datei-Wartezeit (WAITFILE) und/oder die Satz-Wartezeit (WAITRCD) für alle Tabellen in deinem QMQRY zu setzen.

[schatte]

Bist Du Dir sicher, dass es die Job-Wartezeit ist?
Ich würde ehrer sagen es ist die Datei-Wartezeit und/oder die Satz-Wartezeit.
Versuch' mal über OVRDBF die Datei-Wartezeit (WAITFILE) und/oder die Satz-Wartezeit (WAITRCD) für alle Tabellen in deinem QMQRY zu setzen.

WAITRCD hat leider auch nichts geändert.

Es gab nur eine Auswirkung, nachdem ich die Tabelle per CHGPF und Angabe von WAITFILE(3600) geändert habe. Aber das möchte man ja nicht als Defaultwert ändern, dafür gibt es ja OVRDBF mit genau diesem Parameter.
Das der OVRDBF dafür eigentlich verwendet werden kann, findet man auch in folgender IBM i Doku: https://www.ibm.com/docs/en/i/7.5.0?...-locking-files

Ein OPNDBF hingegen funktioniert wie erwartet, hier greift auch der mit OVRDBF gesetzte WAITFILE Wert.

Klingt für mich nach einem IBM i Fehler. Oder was meint ihr?

[Fuerchau]

Hast du denn mal die Änderung des QueryTimeOut mit CHGQRYA geprüft?
Immerhin zieht der bei SQL-Aktivitäten generell, nicht nur bei Abfragen.

[schatte]

Hast du denn mal die Änderung des QueryTimeOut mit CHGQRYA geprüft?
Immerhin zieht der bei SQL-Aktivitäten generell, nicht nur bei Abfragen.

Der Parameter QRYTIMLMT im Befehl CHGQRYA steht auf *SYSVAL und DSPSYSVAL QQRYTIMLMT auf *NOMAX, somit keine Beschränkung.
Zum Test habe ich CHGQRYA QRYTIMLMT(120) ausgeführt und danach das SQL. Das Ergebnis ist jedoch das gleiche. Abbruch nach 30 Sekunden mit der Meldung SQL0913 "Row or object MYTABLE in MYLIB type *FILE in use.".

[Fuerchau]

Die Frage ist auch, ob der OVRDBF (OPM) auch für SQL mit ACTGRP(*JOB) gesetzt wurde.
Kannst du u.U. den STRQMQRY in einen RUNSQL native umbauen?

[schatte]

Die Frage ist auch, ob der OVRDBF (OPM) auch für SQL mit ACTGRP(*JOB) gesetzt wurde.
Kannst du u.U. den STRQMQRY in einen RUNSQL native umbauen?

Ich hatte beim OVRDBF OVRSCOPE(*JOB) angegeben, um sicherzugehen, dass es auf jeden Fall greift.

Getestet habe ich mit STRQMQRY und STRSQL. Einfach SELECT * FROM MYTABLE welche auf einer anderen Session per ALCOBJ gesperrt wurde (wie anfangs beschrieben).
Beim RUNSQL dann create table qtemp/x as(SELECT * FROM MYTABLE) with data da dort kein direkt unterstützt wird.

[schatte]

Als Workaround führe ich jetzt vor dem STRQMQRY folgendes in einer Subroutine aus:

OVRDBF     FILE(&TBL) TOFILE(&LIB/&TBL) + 
             WAITFILE(3600) OVRSCOPE(*CALLLVL)
OPNDBF     FILE(&TBL) OPTION(*INP)
CLOF       OPNID(&TBL)

Ich bin trotzdem der Meinung, dass das auch bei SQL greifen müsste. Vielleicht lege ich noch einen IBM Fall an.

[Fuerchau]

SQL SQE hat da leider eigene Verfahren entwickelt und die CQE gibts ja nun nicht mehr.
U.A. wird auch die QAQQINI (Global, je Lib) verwendet:

https://www.ibm.com/docs/en/i/7.5.0?...ty-concurrency

Ich finde allerdings zu den Einstellungen explizit nichts, was auf einen Lock Wait Timeout hindeutet.
https://www.ibm.com/docs/en/i/7.5.0?topic=qaqqini-query-options

Vielleicht doch ein Ticket aufmachen.

[E305GL]

Als Workaround führe ich jetzt vor dem STRQMQRY folgendes in einer Subroutine aus:

OVRDBF     FILE(&TBL) TOFILE(&LIB/&TBL) + 
             WAITFILE(3600) OVRSCOPE(*CALLLVL)
OPNDBF     FILE(&TBL) OPTION(*INP)
CLOF       OPNID(&TBL)

Ich bin trotzdem der Meinung, dass das auch bei SQL greifen müsste. Vielleicht lege ich noch einen IBM Fall an.

da du ja sowieso den aufruf im cl ausführst kannst ja die verfügbarkeit der tabelle vor dem SQL abfragen und in eine wait-warteschleife bis zum sankt nimmerleinstag ausführen...

[Pikachu]

Oder vielleicht ALCOBJ OBJ((&LIB/&TBL *FILE *EXCLRD)) WAIT(3600) warten lassen?