RE: Max Records in Physical or Printer Files - To Max or Not To Max...

[Jim Damato <jdamato@xxxxxxxxxxxxxxxxx>]

> Rick Rayburn:
>We'd like to create all applicable file objects to size(*NOMAX) but perhaps
>someone can educate us first to any extenuating circumstances that could
>arise from this decision.

Wherever possible I change physical files to SIZE(*NOMAX) (and
REUSEDLT(*YES)!).  I like to leave a limit on printer files.  My mindset is
that programs should be adequately tested so that they do not run amok and
overrun physical files, and disk.  Many reports, however, can be run with
absurd user selection criteria (you decide if "absurd" modifies "user" or
"selection criteria").

I've always had the luxury of working on systems with 24x7 Operations staff
and large DASD pools.  If a physical file were overrun the operators would
catch the critical storage message long before it became a disaster.  For
these reasons I've always thought that the worry of a runaway update/write
program were a non-issue.  Since 1985 I've never encountered the problem
other than with work files, which would have filled up a spooled file
eventually.

> Bill Reger:
>The important thing is to consider
>the current requirements, reasonable growth expectations, data entry plans,
>and purge criteria.
>...In my opinion, setting files to
>*NOMAX should not be a substitute for proper Data Analysis.

I'm having a hard time reconciling my practices with Bill Reger's post
because he seems right, but I don't know the difference between file sizing
and the automatic sizing due to *NOMAX.  Back in the '38 days we used to
take some pain to plan initial size and increments to create meaningful file
sizes and to balance file increments between waste and fragmentation.  These
days my systems cook along just fine under *NOMAX.  I have no idea how much
initial space a physical file will take and how large the increments will be
under *NOMAX.

Also, assuming I create a file with a well tuned initial size, am I not
depending on OS/400 to smooth it across my disks anyway?  I know my Oracle
DBA's break their necks to spread out large tables across disk manually.
They don't like to let the database automatically generate extents because
it would be difficult to undo the fragmentation.  One of the reasons to tune
increments is to prevent contention, but can I really know what I'm doing
when the OS is distributing the file at an object level?

Can anyone recommend a good source explaining how SIZE(*NOMAX) actually
works within physical files, and how large objects in general are spread
across disk?  To me, this is the heart of the matter.

-Jim

James P. Damato
Manager - Technical Administration
Dollar General Corporation
<mailto:jdamato@dollargeneral.com>