rgzpfm bei objlck

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

[BenderD]

... da gibt es durchaus Spie(ge)l(ungs)software, die dann beim RGZPFM einen SAVRSTOBJ hinterherfeuern, was dann auch die Leichen im Keller wieder aufräumt.

D*B

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.