× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Steve,

The RGZPFM that put the system on its knees was already running. It was launched via a Job Schedule Entry. I was trying to tame a RGZPFM that was already running. Once it was launched there was no turning back. The plan was to set the access path maintenance to *DELAYED on the logicals so they could be rebuilt one at a time. Unfortunately, the scheduled job beat them to that.

I think Al has come up with the best possible method of taming a rouge RGZPFM already running with the CHGQRYA command and the DEGREE parameters for systems running OS/400 V5R2 By setting DEGREE to *NONE and the thread count to 2 I think I could have changed the behavior so other users were not impacted as badly. That night I could have went back in and changed to DEGREE parms back and let it rip.

Rob also pointed out the new stuff we get with RGZPFM in V5R3. It allows you to specify the rebuild of access paths and it allows the QDBSRVxx jobs to be canceled if necessary. I restored the data library containing this monster file and its logicals on an i5 520 this morning. I am going to test how good or bad this new stuff is. I am also going replicate the RGZPFM as it was launched Sunday and see how the CHGQRYA would work.

The only real remaining question is how long it takes the system to respond to the CHGQRYA? I will know here soon! Thanks!

Mike Shaw


Steve Richter wrote:

On Tue, 28 Dec 2004 15:25:42 -0800, Mike <mshaw2456@xxxxxxxxxxx> wrote:


Folks,

Over the holiday one of our developers deleted 20,000,000 records from a
physical file as they were no longer needed.  This HUGE physical file ( even
after 20 M records deleted) has 19 logicals built over it.  On Sunday
morning, a scheduled job ran (which was not planned), that did a RGZPFM over
this mess.  The end result was that it put an 870 8-Way running SMP on it's
knees for 13 hours.   No matter what I tried, I could not get the
IDX-<access path name> running under QDBSRVxx jobs to ease up.

I did find the following Knowledge Base document (after the fact):

http://www-912.ibm.com/s_dir/slkbase.NSF/ce197905697c4c6086256a4f007978f7/17
bb5f5d63273150862565c2007ce9e5?OpenDocument

Now for my $64 K questions: Had I used the EDTRBDAP command, could I have
put the active access path rebuilds on hold? Would the active IDX entries
have to have completed before the *HLD entries would have taken effect? I
am trying to understand how I could have got this under control in the least
amount of time.



Mike,

You could have used the RMVM command to remove the members from all of
the logical files.  Then do the RGZPFM.  Then ADDLFM one logical file
at a time in a batch CL.

-Steve




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.