Re: *nomax on file size.

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