On 21-Mar-2012 08:51 , Gqcy wrote:
I just read a techie tip,
http://www.itjungle.com/fhg/fhg032112-story02.html
While suggesting "*NOMAX does not mean that a file can contain an
infinite number of records" is very true. But to imply that ""There is
no danger of filling up the disk space" is very far from true. A
sufficiently small amount of [available] storage can be used up quickly,
even using a relatively simple record format and a small number of rows.
There are customers who know that claim is untrue, having experienced
outages as a direct side effect of program(s) having gone "into a loop
and fill up the disk space with output operations" or even legitimate
and properly operating functions like CPYF or RGZPFM; that the DB
operations did not cause the crash, caused instead by a critical OS
operation failing to complete due to no available storage, is of little
consolation in such cases.
what if I am currently running at 70% disk used, on a 600GB ASP?
Any snapshot is interesting, but concurrency deprecates a measurement
from a point-in-time; i.e. not like DASD is sequential media such that
growth during one operation must complete before growth starts in the
next operation. Also temporary storage within the same pool would give
more variability; e.g. a cross join implemented using temporary running
output to a database file with *NOMAX grows in both temp and permanent
storage which is effectively a double-down on storage depletion.
what if the rogue file has 50 logical files with big keys?
The growth would be to the physical dataspace directly, and then
would include also growth in maintained indexes over that data. If the
access paths had maintenance delayed or turned off, then the growth
would await activation of maintenance. There could also be a TRIGGER
that does something to take storage. The file may be journaled, and the
access paths may be journaled; logging gives concurrent growth.
I know my SQL tables are *NOMAX, so maybe it's no big deal...
If there are means activated to intervene before /critical storage/
limits have been exceeded, then SIZE(*NOMAX) could be of minimal general
concern. One part of an overall approach, includes setting a "Maximum
allowed storage" MAXSTG on each [group] USRPRF.
Personally I would set a _much larger_ SIZE() default on CRTPF [for
initial size mostly], and I always customized the _model outfiles_ [and
printer files] in QSYS libraries to have much larger values. In neither
case did I specify *NOMAX as the new\changed default.
Regards, Chuck
midrange.com
