Runsql aus CL-Programm funktioniert nicht mehr

[nico1964]

Da du den SQL-Befehl ja kennst, ersetze das einfach durch einen QM-Query (STRQM) und ersetze den Befehl mit STRQMQRY.

Also mein Kollege und ich habe das jetzt mal genauer untersucht. Ursprünglich war das ein Befehl eines Drittanbieters. Irgendwann in grauer Vorzeit(2002), wird sind ja alle schon Dino's, haben dann ehemalige Kollegen was eigenes geschnitzt. Diese Lösung entspricht im großen und ganzen dem, was Hr. Fuerchau geschrieben hat. D.h. das sollte so funktionieren.
Das mit der Sperre ist aber ein ganz anderes Problem. Denn nachdem wir das auf unsererm Testsystem ausprobiert haben, hat es dann auf einmal funktioniert. Der einzige Unterschied zu früher (vor V6R1) ist der, dass das Programm um ein vielfaches länger für diesen einfachen delete benötigt. Dieses länger liegt leider im Minutenbereich.

lg
Andreas

[Fuerchau]

Der SQL-Optimizer ab V6R1 versucht (wie oben gesagt) zuerst einen CLRPFM. Auf Grund der Dateiwartezeit von 60 Sekunden erfolgt halt erst hinterher der satzweise Delete.

Du kannst das umgehen, in dem du eine simple Where-Klausel anhängst, die dann alle Sätze umfasst.

Der alte Optimizer ist ab V6 wohl abgeschafft, so dass hier diese Probleme mit dem Neuen auftreten.

[BenderD]

... das ist kein ganz anderes Problem!!!
das ist genau der Effekt, den ich bereits mehrfach erwähnt habe.

delete * from ... einmal Satz weise - stört sich nicht an locks auf die Teildatei, sondern holt sich nacheinander die Satzsperren, sperrarm und lässt konkurrierende open auf die Teildatei zu.

delete * from als CLRPFM ausgeführt - geht wesentlich schneller, stirbt aber an konkurrierenden open auf die Teildatei

letzteres sollte eigentlich nur versucht werden, wenn die Datei frei ist => ergo Bug!!!

[andreaspr@aon.at]

Das ein DELETE * FROM TAB1 als CLRPFM ausgeführt wird kann ich mir nicht vorstellen.

Bei einem DELETE (egal ob mit Where oder ohne) stehen nach einem DSPFD TAB1 bei "Gesamtzahl gelöschter Sätze" die Anzahl der gelösten Sätze.
Bei einem CLRPFM steht dort immer 0 (wie Bender so schön sagen würde: in Worten null )

[nico1964]

Das ein DELETE * FROM TAB1 als CLRPFM ausgeführt wird kann ich mir nicht vorstellen.

Bei einem DELETE (egal ob mit Where oder ohne) stehen nach einem DSPFD TAB1 bei "Gesamtzahl gelöschter Sätze" die Anzahl der gelösten Sätze.
Bei einem CLRPFM steht dort immer 0 (wie Bender so schön sagen würde: in Worten null )

Hallo,
und da steht dann null, haben es gestern auf alle möglichen Wege durchgespielt.
LG

[B.Hauser]

Das ein DELETE * FROM TAB1 als CLRPFM ausgeführt wird kann ich mir nicht vorstellen.

Bei einem DELETE (egal ob mit Where oder ohne) stehen nach einem DSPFD TAB1 bei "Gesamtzahl gelöschter Sätze" die Anzahl der gelösten Sätze.
Bei einem CLRPFM steht dort immer 0 (wie Bender so schön sagen würde: in Worten null )

Das stimmt schon!
Sofern beim Delete * from ohne Where-Bedingungen kein Lock auf der Datei besteht, wird ein CLRPFM ausgeführt. Sofern ein Lock auf der Datei besteht werden lediglich die Sätze gelöscht, jedoch kein RGZPFM ausgeführt, der die gelöschten Sätze auf physisch aus der Datei entfernen würde. Konnte ein CLRPFM ausgeführt werden, so ist auch in diesem Fall die Anzahl der gelöschten Sätze 0 (in Worten NULL)

... das ist übrigens nicht erst seit Release 6.1 so, sondern wurde bereits mit Release V5R3M0 implementiert.

Birgitta

Birgitta

[andreaspr@aon.at]

Das stimmt schon!
Sofern beim Delete * from ohne Where-Bedingungen kein Lock auf der Datei besteht, wird ein CLRPFM ausgeführt. Sofern ein Lock auf der Datei besteht werden lediglich die Sätze gelöscht, jedoch kein RGZPFM ausgeführt, der die gelöschten Sätze auf physisch aus der Datei entfernen würde. Konnte ein CLRPFM ausgeführt werden, so ist auch in diesem Fall die Anzahl der gelöschten Sätze 0 (in Worten NULL)

... das ist übrigens nicht erst seit Release 6.1 so, sondern wurde bereits mit Release V5R3M0 implementiert.

Birgitta

Hi Birgitta,

tut mir leid, aber ich kann das nicht nachvollziehen. (5.4 und 7.1).
Mit WRKOBJLCK sehe ich, dass es keine Sperren für die Tabelle gibt, dennoch wird kein CLRPFM ausgeführt.
Wenn das bei euch funktioniert würde es mich sehr interessieren, warum es bei mir auf beiden Systemen nicht geht.
Ich schließe auch gar nicht aus, dass ich eventuell was nicht beachtet habe, komisch ist es dennoch.

[BenderD]

Hi Birgitta,

tut mir leid, aber ich kann das nicht nachvollziehen. (5.4 und 7.1).
Mit WRKOBJLCK sehe ich, dass es keine Sperren für die Tabelle gibt, dennoch wird kein CLRPFM ausgeführt.
Wenn das bei euch funktioniert würde es mich sehr interessieren, warum es bei mir auf beiden Systemen nicht geht.
Ich schließe auch gar nicht aus, dass ich eventuell was nicht beachtet habe, komisch ist es dennoch.

... da steht "may be deleted using either a clear operation..." not "are deleted..."

D*B

[BenderD]

Das ein DELETE * FROM TAB1 als CLRPFM ausgeführt wird kann ich mir nicht vorstellen.

Bei einem DELETE (egal ob mit Where oder ohne) stehen nach einem DSPFD TAB1 bei "Gesamtzahl gelöschter Sätze" die Anzahl der gelösten Sätze.
Bei einem CLRPFM steht dort immer 0 (wie Bender so schön sagen würde: in Worten null )

Das ist keine Frage des Glaubens oder der Vorstellung, das ist dokumentiertes Verhalten seit Version 5.3. Für die Ungläubigen unter uns RTFM (SQL Reference V5R3 S. 651).

D*B

[andreaspr@aon.at]

Das ist keine Frage des Glaubens oder der Vorstellung, das ist dokumentiertes Verhalten seit Version 5.3. Für die Ungläubigen unter uns RTFM (SQL Reference V5R3 S. 651).

D*B

Danke für die Doku.
Dass statt einem DELETE ein CLRPFM ausgeführt wird unterliegt mehreren Kriterien.
Bei mir dürfte es daran liegen dass es zu wenige Datensätze sind die gelöscht werden.

Nachtrag:
@nico1964: Eventuell der neuen Maschiene nicht allen Kriterien erfüllt?

[nico1964]

Nachtrag:
@nico1964: Eventuell der neuen Maschiene nicht allen Kriterien erfüllt?

Welche Kriterien???
Einfach
Delete from file

[Fuerchau]

Um einen CLRPFM zu verhindern einfach "delete from file where myfield <> x'FF'"

Ggf. reicht auch schon ein "delete from file where 1=1", da alleine eine Where-Klausel eben das CLRPFM verhindert.

Und WRKOBJLCK zeigt ggf. erst mal keine Locks an, erst F6->Teildateien zeigt die Locks.

Ggf. liegt halt doch ein Bug vor, wenn der neue SQL-Optimizer erst mal CLRPFM versucht und nicht mehr die Locks vorher prüft.
Dies könnte auch ein Zeitproblem sein, da ja zwischen Prüfung und Lock setzen ein anderer wieder schneller sein könnte.

CLRPFM wird bei auch nicht bei Journalisierung durchgeführt, da ja sonst kein Rollback möglich wäre (bzw. späteres Wiederherstellen aus dem Journal).