RE: Increase Member Size while active

What are the reasons for NOT having *NOMAX on a file size?
1 - Fear of a runaway job eating all your disk
2 - You want to do some predictive planning to clean up files.

The default for DDL created files is to use *NOMAX.
QSYS.LIB objects aren't your only risk of a runaway job eating all your system. I have stream files bigger than my QSYS.LIB objects. You should have better ways of monitoring for runaway disk jobs. But if this is your "defense in depth" approach I can respect that.

However, you ran into an issue where you failed to monitor and handle the file nearing full in a nondisruptive method. One suggestion is to query this for members (aka partitions in DB2 parlance) nearing capacity:
https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_74/db2/rbafzcatsyspstat.htm
A nightly/weekly job can be used for predictive emails.
It's also useful for analyzing partitions with a large number of deleted rows. These you might want to run RGZPFM on.

Here's another useful tool:
select
*
from qsys2.syslimits
where limit_id in(15000, 15003) -- see select * from qsys2.sql_sizing
;
https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_74/rzajq/rzajqviewsyslimits.htm


Rob Berendt