Re: Adding an LF decreased performance drastically

[dr2@xxxxxxxx]

If you're doing a clrpfm and then what appears to be a full PF rebuild,
you're faster to dlt/rmvmbr(?) on the LF's and then either addmbr or
crtlf after the rebuild or you're updating the access path(s) for each
add...

On 2022-04-23 08:35, Vance Stanley via MIDRANGE-L wrote:

> Maybe time to switch to ddl on that table. 
> On Friday, April 22, 2022, 02:23:00 PM CDT, x y <xy6581@xxxxxxxxx> wrote:  
>
> IBM"s advice in the past (IIRC) was to remove the LF members if you're
> changing more than ~15% of the records.  You can automate this with a
> quick-and-dirty CL program: DSPDBR to an outfile, read the file, remove the
> members, maintain the PF, read the DSPDBR OUTFILE, add the members back.
>
> On Fri, Apr 22, 2022 at 11:18 AM <smith5646midrange@xxxxxxxxx> wrote:
>
> > We have a job that writes about 1.5B records to a PF.  When the job starts,
> > it does a CLRPFM and then starts dumping records into the PF.
> >
> > We recently added an LF over the PF with no mods to the original program
> > (LF
> > will be used later in the stream by something else) and the job went from
> > approx. 2 hrs to an estimated 11 hrs.  We killed it after the normal 2 hour
> > window with less than 20% of the records written.
> >
> > While trying to determine why, one thing that we noticed is the job I/O
> > count was different with and without the LF.  We found that without the LF,
> > the output blocking factor is a pretty decent number of records (I/O count
> > is WAY less than RRN).  However, when we created the LF, the I/O count and
> > the RRN are almost identical (like blocking is ignored).  The LF is not
> > unique keyed, just a normal keyed logical.
> >
> > I've never noticed this before but I've never really paid attention to the
> > I/O count on output files.  Is this a normal thing for an LF to eliminate
> > the blocking factor of the output and make it 1 for 1 or is there something
> > that we muffed up in the create of the LF?
> >
> > I know we can change the LF to *DLY and stuff like that but we just want to
> > understand what happened and why so we know for future reference.
> >
> > Thanks.
> >
> > --
> > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
> > To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
> > To subscribe, unsubscribe, or change list options,
> > visit: https://lists.midrange.com/mailman/listinfo/midrange-l
> > or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
> > Before posting, please take a moment to review the archives
> > at https://archive.midrange.com/midrange-l.
> >
> > Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
> > questions.
> >
> > Help support midrange.com by shopping at amazon.com with our affiliate
> > link: https://amazon.midrange.com
> -- 
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: https://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at https://archive.midrange.com/midrange-l.
>
> Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.
>
> Help support midrange.com by shopping at amazon.com with our affiliate link: https://amazon.midrange.com