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.
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
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.
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
...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
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 .
Free Guide: Managing storage for virtual environments
Complete a brief survey to get a complimentary 70-page whitepaper featuring the best methods and solutions for your virtual environment, as well as hypervisor-specific management advice from TechTarget experts. Don’t miss out on this exclusive content!
Discuss This Question: 7  Replies