Cannot end RGZPFM on V5R4 (Journaled file)

15 pts.
Tags:
AS/400
AS/400 performance
DB2 Universal Database
ENDJOB
Journaling (Exchange)
Recovery
REUSEDLT
RGZPFM
RPG
V5R4
Batch job RGZPFM on V5R4 not complete after 3 days. I issued an ENDJOB, and job is not completely ended 1.5 days later. The file is journaled and is very large. SBMJOB CMD(RGZPFM FILE(MYLIB/MYFILE) KEYFILE(*NONE) ALWCANCEL(*YES) LOCK(*SHRUPD)) How can I end this job? If MYFILE is damaged, I can delete it and restore it from a backup. I just need to end the job.

Answer Wiki

Thanks. We'll let you know when a new response is added.

You don’t mention how you have tried to end the job. Have you used ENDJOB with OPTION(*IMMED)?

If so, have you also tried ENDJOBABN (End Job Abnormal)?

After the reorg of the physical file is finished, the RGZPFM command will rebuild all of the logical files attached to the physical file. Also, if you are allowing the users to change the file (Add/Delete/Update) while the reorg is processing you will add to the amount of time needed to finish the job.

Discuss This Question: 6  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
  • Znason
    Why didn't you stop Journaling prior to the reog?
    460 pointsBadges:
    report
  • AS400DBA
    I finally got the job to finish by using ENDJOBABN (End Job Abnormal). This was on our test box, so we only had 2 real issues. 1- Operators had not been able to get a system backup in 3 days. 2- Since I wanted to be able to cancel the reorg, it was submitted with ALWCANCEL *YES, which meant it had to be journalled. The journal receivers were taking up too much space on the system and we still had 25% more to go. Day 1 - RGZPFM started (System storage @ 52%) Day 2 - system storage now @ 71% Day 3 - Still running, job had created 120 journal receivers, about 75% complete. System storage now at 83%. I ended the job with ENDJOB *IMMED. We were concerned about the system crashing because of storage. (I probably should have deleted some of the journal receivers instead of ending the job. I was not sure if I could.) Day 4 - Job is at END status but is still ACTIVE. Day 5 - Still not ended. ENDJOBABN was issued and the job ended within 5 minutes. System storage still @ 83% but we will be deleting the 120 extra journal receivers. Since this is a test box, I will turn off the journalling and submit the RGZPFM with ALWCANCEL *NO. My other option is to use CPYF as suggested in some articles. For the question of "Why didn't you turn off journalling first?" - The file had to be journalled in order to use the ALWCANCEL *YES and I wanted to be able to cancel it, if it was taking too long. (so much for being able to cancel it) Thanks for all the input. I would still love to hear other suggested options or solutions.
    15 pointsBadges:
    report
  • Gilly400
    Hi, I assume (as you're doing a reorg with no keyfile) that you're just trying to remove deleted records from this file to get some space back? You could try doing a CHGPF REUSEDLT(*YES) which will allow re-use of deleted records so you won't need to reorg to get rid of them. Cheers, Martin Gilbert. .
    23,730 pointsBadges:
    report
  • Yorkshireman
    You say the file is very large - so we are talking some millions of records. How big is that number? How many access paths exist over the file? How much storage does it consume in a passive state - space to copy it? How time critical in terms of restoring service to users? Are alternative strategies available? - save to (tape) to reorganise and reload? Do you have any metrics for the job so far? - if not, rerun at least some of it with Performance monitoring turned on and discover exactly what is happening? Yorkshireman
    5,580 pointsBadges:
    report
  • BigKat
    If you have TAATOOLs try using CPRDLTRCD and TRNDLTRCD. The first program moves all records up to what were deleted records and the second lops off the blank records (now at the end of the file). If not, maybe you can drop the logical files (or at least the members), reorg the file, and then recreate the logicals during some scheduled down time
    7,935 pointsBadges:
    report
  • TomLiotta
    Day 1 - RGZPFM started... It's not possible to say a lot because although you give various statistics (e.g., "System storage @ 52%"), there is no context. How much DASD is on the system? What is the size of the file? How many records and how many are deleted? What was the size of the receivers? How many logical files are built over the physical file? Other than statistics... Is the physical file indexed? Why did you use LOCK(*SHRUPD)? Why did you submit to batch? Is there anything unusual about the file? E.g., does it contain any LOB (Blob, CLOB, etc.) columns? Variable-length fields? You were right to point out that ALWCANCEL(*YES) requires journalling to be active. I'm not clear on the part about "...we still had 25% more to go". 25% of what? AFAIK, the receivers would be automatically deleted as soon as the process no longer needed them. If they hadn't been deleted, then entries in the receivers was still needed to complete the reorg. But that might be a function of the attributes you set on the journal. It might also be related to LOCK(*SHRUPD) if anything else was accessing the file. Tom
    125,585 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