Runsql aus CL-Programm funktioniert nicht mehr

[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

[nico1964]

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

Sollte vielleicht so funktionieren, dass wenn kein where definiert ist, löschen von relativer Satznr. 1 bis relativer Satznr. n und nicht clrpfm

lg

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

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

[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

[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).

[andreaspr@aon.at]

Welche Kriterien???
Einfach
Delete from file

So wie ich das jetzt mitverfolgt habe dauert das DELETE in deinem PGM zu lange.
Es könnte also sein, dass das DELETE anderes umgesetzt wird als auf der alten Maschine.
Wenn das der Fall ist liegt das ggf. an folgenden Kriterien:

This technique will only be used
if all the following are true:
v The target table is not a view.
v A significant number of rows are being deleted.
v The job issuing the DELETE statement does not have an open cursor on the file
(not including pseudo-closed SQL cursors).
v No other job has a lock on the table.
v The table does not have an active delete trigger.
v The table is not the parent in a referential constraint with a CASCADE, SET
NULL, or SET DEFAULT delete rule.
v The user issuing the DELETE statement has *OBJMGT or *OBJALTER system
authority on the table in addition to the DELETE privilege.
If this technique is successful, the number of increments (see the SIZE keyword on
the CHGPF CL command) is set to zero.

[BenderD]

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).

Zeitproblem ist das keins, der Job holt sich seine Sperre einfach ohne wait und wenn das nicht geht, dann macht er halt einen satzweisen delete, wenn ers richtig macht.

Rollback würde selbst dann noch gehen, aber kein späteres backward Journal Recovery.

Dieter