AS400DBA
15 pts. | Jan 15 2008 6:05PM GMT
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.
Gilly400
23625 pts. | Feb 20 2008 4:09PM GMT
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.
.
Yorkshireman
3200 pts. | Apr 28 2009 8:46AM GMT
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
BigKat
2480 pts. | Apr 28 2009 1:37PM GMT
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






