Comments on: Cannot end RGZPFM on V5R4 (Journaled file)

By: BigKat

BigKat — Tue, 28 Apr 2009 13:37:40 +0000

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

By: Yorkshireman

Yorkshireman — Tue, 28 Apr 2009 08:46:19 +0000

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

By: Gilly400

Gilly400 — Wed, 20 Feb 2008 16:09:13 +0000

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.
.

By: AS400DBA

AS400DBA — Tue, 15 Jan 2008 18:05:32 +0000

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.

By: Znason

Znason — Mon, 14 Jan 2008 17:51:52 +0000

Why didn’t you stop Journaling prior to the reog?