RGZPFM allow cancel

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

Answer Wiki

Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Discuss This Question: 7  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • TomLiotta
    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
    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.
    49,970 pointsBadges:
    report
  • Mell0rman
    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
    ...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
    MIMIX, Journaling, ALWCANCEL(*YES) may all have to go to resolve this issue and logicals affect reorg performance.
    49,970 pointsBadges:
    report
  • Mell0rman
    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
    Great, thanks for the feedback. Closing the loop doesn't happen often enough. Phil
    49,970 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following