×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
Rob,
Thanks... Not my software or files... this is from our 20-year-old ERP system.
Greg
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxxxxxxxx] On Behalf Of Rob Berendt
Sent: Tuesday, October 13, 2020 10:38 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: 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
midrange.com
