Re: PF member current number of increments larger than the max

[Evan Harris <auctionitis@xxxxxxxxx>]

Hi Roger

I respectfully tend to disagree with this sentiment. I nearly always
recommend *NOMAX in conjunction with monitoring.
Main reasons:
- Over the journey I have seen more production problems due to "Maximum
file size reached..." messages than I have system overflows (though I have
seen a few of those)
- You can create files via WRKQRY (and I guess possibly SQL) that are
automatically created with no. of records *NOMAX so you are exposed to an
overflow via runaway queries anyway
- Systems are larger, so they generally take much longer to fill (but
conversely they are faster so runaway jobs can generate data much
quicker...)
- Monitoring is cheap and easy and you should do it anyway


On Wed, Nov 7, 2018 at 10:53 AM Roger Harman <roger.harman@xxxxxxxxxxx>
wrote:

> VERY VERY VERY VERY VERY VERY bad choice.
>
> Runaway/Rogue job = Disks Full = System Crash
>
> Did I mention it's a bad choice?
>
> Roger Harman
> COMMON Certified Application Developer - ILE RPG on IBM i on Power
>
>
>
>
>
>
>
> From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxx> on behalf of Booth
> Martin <booth@xxxxxxxxxxxx>
> Sent: Tuesday, November 6, 2018 1:05 PM
> To: Midrange Systems Technical Discussion
> Subject: Re: PF member current number of increments larger than the max
>
> I am curious; why aren't you recommending *NOMAX?
>
>
>  On 11/6/2018 2:36 PM, Musselman, Paul wrote:
>  > Jack--
>  >
>  > No, it's not a 'troubled' file-- the data is fine.  It is a sign that
> whomever originally created the file didn't know how much data would be
> stored, and under-estimated the file size.
>  >
>  > The problem is that every time the file fills up an 'increment' of
> records (ie every 100 records you add), the operating system will ask what
> to do about it.  Usually, the option to increment the file and continue is
> taken. This has happened over 42,000 times!
>  >
>  > The cure is to CHGPF and increase the base size of the file, and the
> size of the increments.  Since the file currently has more than 4 million
> records, the changed size should be at least 5 million.  The increment
> should be more than 100.  I recommend the maximum-- 32767.  The maximum
> increments is already 32767, which the file has exceeded by at least 10,000
> increments!
>  >
>  >        CHGPF FILE(LIB/FILE) SIZE(5000000 32767 32767)
>  >
>  > You can't change the file while it's busy-- pick a 'quiet time.'
>  >
>  > Before you change the file, however-- How many deleted records does the
> file contain?  Would reorganizing the file be a good starting point?
>  >
>  >
>  > Paul E Musselman
>  > PaulMmn@xxxxxxxxxxxxx
>  >
>
>  --
>  Booth Martin
> www.martinvt.com
>  (870)576-9371
>  (802)461-5349
>
>  Brain fried -- core dumped
>  --
>  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: https://lists.midrange.com/mailman/listinfo/midrange-l
>  or email: MIDRANGE-L-request@xxxxxxxxxxxx
>  Before posting, please take a moment to review the archives
>  at https://archive.midrange.com/midrange-l.
>
>  Please contact support@xxxxxxxxxxxx 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@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: https://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at https://archive.midrange.com/midrange-l.
>
> Please contact support@xxxxxxxxxxxx for any subscription related
> questions.
>
> Help support midrange.com by shopping at amazon.com with our affiliate
> link: https://amazon.midrange.com