rgzpfm bei objlck

[karin-vogelmann]

hallo *all,

ich weiß, auf eine gelockte file kann man keinen rgzpfm machen.

aber ich gebe die hoffnung nicht auf, daß es vll. inzwischen einen trick 17 gibt??

wenn ja, welcher?

lg, karin

[cbe]

Hallo Karin,

wenn es Dir nur darum geht, gelöschte Sätze wegzubekommen, hilft Dir evtl. das Attribut an der Datei REUSEDLT(*YES).
Wenn Dir die sequenzelle Reihenfolge der Daten beim Lesen ohne Key egal ist, ist das eine praktische Option. Es löscht zwar die Sätze nicht raus, es kommen aber auch keine neuen dazu.

Allerdings darf glaube ich auch hier die Datei nicht gelockt sein, macht man also am besten nach dem nächsten (und letzten) RGZPFM

Gruß,
Christian

[Fuerchau]

Der Trick17 heißt ENDJOB

[holgerscherer]

aber ich gebe die hoffnung nicht auf, daß es vll. inzwischen einen trick 17 gibt??

Hallo Karin,
wie hier schon geschrieben wurde, da gibts keinen Trick17 - ein Reorganize braucht exklusiven Zugriff. Aber in Zeiten von gutem Datenbankdesign und SQL sollte das zweitrangig sein? :-)

-h

[karin-vogelmann]

moin!

das habe ich befürchtet...

aber ok, dann ist es so.

der reusedlt kommt nicht in frage, weil zum chgpf benötigt man auch exklusiven zugriff und wenn ich den schon hätte, könnte ich ja auch gleich den rgzpfm machen.

der endjob hört sich gut an ;-) leider hängt unser gesamtes MQ-subsystem dran, wenn ich das kille, gibt es ärger.

gutes datenbankdesign haben wir ja (an einigen stellen), aber der reorg wurde bislang nicht berücksichtigt und nun habe ich eine datei, die wächst wie hulle und ich krieg den alten schrott nicht mehr raus...


erst mal besten dank für die aufmunternden kommentare!

lg, karin

[B.Hauser]

Hallo Karin,

zwar brauchst Du Exklusiv-Rechte um den RGZPFM ausführen zu können, aber seit Release V5R3 ist es nicht mehr erforderlich, dass der RGZPFM komplett durchgeführt wird.

Wenn Du die Option ALWCANCEL im Befehl RGZPFM auf *YES setzt, kann der Reorg abgebrochen werden. Die bereits ausgeführten Änderungen bleiben erhalten. Wir der Reorg erneut ausgeführt, wird einfach weitergemacht. Wenn Du also nur ein kleines Zeitfenster hast, in dem der Reorg laufen kann, kannst Du diesen auch happchenweise durchführen.

Eventuell solltest Du Dir auch noch die Option KEYFILE(*RPLDLTRCD) im RGZPFM-Befehl ansehen, bei dem werden gelöschte Sätze am Anfang der Datei durch aktive Sätze am Ende der Datei ersetzt. (Sollte allerdings nicht verwendet werden, wenn die Reihenfolge der Sätze eingehalten werden muss, also dann wenn REUSEDLT(*YES) nicht verwendet werden kann.)

Vielleicht hilft das auch schon weiter!

Birgitta

[Fuerchau]

Da du ja gutes Datenbankdesign bereits hast, kannst du ja wohl durchaus REUSEDLT(*YES) einsetzen.

Ich würde sowohl den CHGPF als auch den RGZPFM beim nächsten IPL starten lassen.

[kitvb1]

Here is an open source tool: RGZPFPCT

RGZPFPCT - RGZPFM by percentage deleted records - EcofIT Support Portal

• It checks for locks before doing a RGZPFM
• You can choose the % threshold
• You can choose Library: named, *LIBL, *USRLIBL, *CURLIB, *ALL, *ALLUSR

[itec01]

Hat jemand Erfahrungen mit dem RGZPFM ALWCANCEL(*YES)?

Ich denke, der eigentlich Lauf wird länger sein, nur wieviel? Wir haben 3 Dateien, die LF (ca. 20 Stück) sind über die 3 Dateien gejoined und die eine Datei enthält ca. 75 Mio. Sätze.

Wie schnell bricht der reorg Job ab?
Wieviel läuft er länger als ohne alwcancel?

Danke.

[BenderD]

... ich habe den Fred erst jetzt gesehen, der ALWCANCEL ist nur der uninteressante Teil der Angelegenheit, der Parameter LOCK ist die entscheidende Sache. Der RGZPFM gibt sich seit V5R3 mit weniger Sperre zufrieden:
RGZPFM ALWCANCEL(*YES) LOCK(*EXCLRD) lässt lesen während des reorgs zu (dem LOCK(*SHRUPD) würde ich nicht trauen.
Der ALWCANCEL sollte weitgehend Laufzeit neutral sein, soweit man ihn nicht abbricht. Der LOCK(*EXCLRD) darf nur wenig Strom kosten, soweit er korrekt implementiert ist. Der weitergehende LOCK(*SHRUPD) packt zumindest Wartezeiten drauf und kann wohl die Eingangsfolge nicht sicherstellen (braucht man die nicht, sollte man ohnehin reuse deleted records auf *YES einstellen und auf den RGZPFM verzichten.

D*B

[itec01]

Danke, ich würde auch gerne auf den RGZPFM verzichten und den REUSE delete nehmen, jedoch gibt es vermutlich Probleme mit unserer Spiegelungssoftware. Da sind wir noch am klären.

[Fuerchau]

Wenn eine Spiegelung mit dem RGZPFM klar kommt (schließlich werden auch da neu RRN's vergeben), sollte ein REUSEDLT(*YES) auch unkritisch sein.

Der Reorg bricht ansonsten nicht von selber ab sondern nur bei Systemanfrage 2 bzw. Job-Ende.