RGZPFM allow cancel

Mell0rman

270 pts.

Tags:

iSeries V5R4MO

I have run a RGZPFM with ALWCANCEL(*YES) RBDACCPTH(*OPTIMIZE)over a large file on a couple of occasions. After 14hrs the job is ended as the file is needed by applications. According to the IBM Website at the next run of this command the system will determine if the Re-org will pick up where it left off or if to start from scratch again, depending on the number of changes made to the file. I'm wondering if there is a way to tell in advance which option the system will take at next run, If the file is just starting again each time from scratch then there is no point running the re-org as it will not complete in the window, so no benefit is being gained. Anyone know the rule? Changing the file to reuse deleted records is not an option.

Software/Hardware used:
OS 400 V5R4M0

Asked: May 30, 2012 1:20 PM Last updated: June 13, 2012 2:54 AM

Answer Wiki

Discuss This Question: 7 Replies

TomLiotta May 30, 2012 10:36 PM GMT

I'm wondering if there is a way to tell in advance which option the system will take at next run,... I suspect that there is with sufficient low-level programming, but IBM says 'no'. Changing the file to reuse deleted records is not an option. Why not? That almost contradicts with the use of RGZPFM. Are you specifying KEYFILE(*NONE) or KEYFILE(*RPLDLTRCD)? (Or some other value?) Tom

125,585 pointsBadges:

report
philpl1jb May 30, 2012 11:29 PM GMT

Based on your discription, it's not likely that this will ever succeed, Without a sucessful reorganize this problem will just continue to grow. 1. Remove any unnecessary logicals and indexes 2. Change any logicals that won't be necessary for immediate processing to Rebuild DELAY 3. Use LOCK Excl with the RGZPFM 4. Get as much space as possible in the ASP 5. Other activity on system should be kept to a minimum.

54,090 pointsBadges:

report
Mell0rman May 31, 2012 2:05 PM GMT

Hi yes run with KEYFILE(*NONE) the process is run by omitting the weekly/monthly backup on the production system to gain maximum uptime for this reorg with the system nearly in a restricted state. I just wish I could tell if any progess was being made, it seems to be all or nothing and no way to tell if the process would complete in X number of runs. Anyone used the MIMIX/RGZACTF command, I'm thnking of using this command and setting it off one weekend, it can then continue into the week re-organizing the copy file and applying updates if not finished, the second weekend the original file will be replaced with the copy and access paths rebuilt. Not used it before so a little worried running it on the production system but may be the answer

270 pointsBadges:

report
TomLiotta May 31, 2012 8:21 PM GMT

...run with KEYFILE(*NONE)... That can be the slowest method, but whether it's your best choice depends on the reason for this: Changing the file to reuse deleted records is not an option. KEYFILE(*RPLDLTRCD) can be much faster, but it will change the physical sequence of some rows. If this is still a file that depends on physical sequence, you have fewer choices. Tom

125,585 pointsBadges:

report
philpl1jb Jun 2, 2012 3:23 PM GMT

MIMIX, Journaling, ALWCANCEL(*YES) may all have to go to resolve this issue and logicals affect reorg performance.

54,090 pointsBadges:

report
Mell0rman Jun 12, 2012 2:14 PM GMT

Well on the third run of this re-org, the file completed in four hours, which is good news All the same settings as previously used were used again. So the re-org looks to have started from its last finish point and not from the beginning again. It seems a real shame we can find no flag or info recorded on the system to indicate percentage of progression while trying to do this work .

270 pointsBadges:

report
philpl1jb Jun 13, 2012 2:54 AM GMT

Great, thanks for the feedback. Closing the loop doesn't happen often enough. Phil

54,090 pointsBadges:

report