Runsql aus CL-Programm funktioniert nicht mehr

[nico1964]

Ist RUNSQL überhaupt ein System-Befehl?
Ich kenne nur RUNSQLSTM und finde auch RUNSQL nicht auf meiner Maschine.

Sollte der Befehl aus einem Fremdprodukt kommen, sollte der Hersteller kontaktiert werden, vielleicht wird der Befehl unter 6.1 einfach nicht mehr (richtig) unterstützt.

Birgitta

Ja hast recht, habe vorher nicht nachgeschaut. Einfach nur das Programm angeschaut. Ist ja auch eine riesen Anwendung, die wir da am Laufen erhalten müssen.
Werde mal nachfragen, ob die was neueres für uns haben. Ist nämlich das einzige Teil, was wir aus diesem Produkt noch im Einsatz haben.

Danke für eure Hilfe.

LG
Andreas

'Langsam am verzweifeln mit RTC und RDp'

[Fuerchau]

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

[BenderD]

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

... und habe dann dasselbe Problem, denn STRSQL macht nix anderes - und das Problem kommt von der Datenbank, die sollte nämlich den CLRPFM nur in Erwägung ziehen, wenn sie die erforderliche Sperre kriegt!
Eventuell hilft auch ein Workaround und die DB läss sich narren mit delete from ... where 1= 1

D*B

[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