View Full Version : Runsql aus CL-Programm funktioniert nicht mehr
Nachtrag:
@nico1964: Eventuell der neuen Maschiene nicht allen Kriterien erfüllt?
Welche Kriterien???
Einfach
Delete from file
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
31-08-11, 09:21
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.
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
Also haben heute nochmals das ganze durchgespielt:
V5R4 aktuellster PTF-Stand
User steht auf einem Record in dem betroffenen File. Aufruf des CLPGM, wie am Anfang erwähnt. Programm läuft ohne Probleme durch.
V6R1 aktuellster PTF-Stand
User steht auf einem Record in dem betroffenen File. Aufruf des CLPGM, wie am Anfang erwähnt. Programm erhhält LCK und läuft nach einiger Zeit durch ohne Probleme durch.
Was uns zur Ansicht bringt, daß Hr. Fuerchau mit seiner 3. Antwort recht hat. Eigentlich nennen wir sowas verschlimmbessern.
LG
:rolleyes: