Re: RGZPFM Question

[Mike <mshaw2456@xxxxxxxxxxx>]

Al,

I would agree with that as well.  Going from being I/O bound to CPU 
bound is not much improvement. 

Happy New Year to all!

Regards,

Mike Shaw

Al Barsa wrote:

> At the end of the day, this will just as much CPU work that has to be done.
>
> Happy New Year
>
> Al
>
> Al Barsa, Jr.
> Barsa Consulting Group, LLC
>
> 400>390
>
> "i" comes before "p", "x" and "z"
> e gads
>
> Our system's had more names than Elizabeth Taylor!
>
> 914-251-1234
> 914-251-9406 fax
>
> http://www.barsaconsulting.com
> http://www.taatool.com
> http://www.as400connection.com
>
>
>
>                                                                           
>             Steve Richter                                                 
>             <stephenrichter@g                                             
>             mail.com>                                                  To 
>             Sent by:                  Midrange Systems Technical          
>             midrange-l-bounce         Discussion                          
>             s@xxxxxxxxxxxx            <midrange-l@xxxxxxxxxxxx>           
>                                                                        cc 
>                                                                           
>             12/30/2004 01:46                                      Subject 
>             PM                        Re: RGZPFM Question                 
>                                                                           
>                                                                           
>             Please respond to                                             
>             Midrange Systems                                              
>                 Technical                                                 
>                Discussion                                                 
>             <midrange-l@midra                                             
>                 nge.com>                                                  
>                                                                           
>                                                                           
>
>
>
>
> 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
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>
>
>
>