I ditto Charles and Buck,
We changed the default on CRTPF *nomax and REUSEDLT *yes.
There are a few exceptions, a few apps use *RRN or EOF triggers, in this case REUSEDLT is no.
Monthly, I have a few utilities, using AJS, CL, WRKQRY
1) Disk Growth GT 100 mb - QSYS/RTVDSKINF , comparing the difference from same file 30 days prior ( INC = t02.diobsz - t01.diobsz) INC GT 100000000
2) Large Objects GT 1 gb QSYS/RTVDSKINF DIOBSZ GT 1000000000
3) Ck dlt recs for reorg while active- - DSPFD FILE(*ALL/*ALL)
STRJRNPF FILE(&MBLIB/&MBFILE) JRN(QGPL/RGZPFM)
SNDPGMMSG MSG('RGZPFM starting for ' *BCAT &MBLIB *BCAT +
'/' *BCAT &MBFILE *BCAT '.')
RGZPFM FILE(&MBLIB/&MBFILE) MBR(&MBNAME) +
RBDACCPTH(*NO) ALWCANCEL(*YES) +
LOCK(*SHRUPD) /* rgzpfm while active */
MONMSG MSGID(CPF2981 CPF3135 CPF9801 CPF9809 +
CPF9810 CPF9820 CPF2982) EXEC(GOTO +
CMDLBL(ERROR2))
ENDJRNPF FILE(&MBLIB/&MBFILE) JRN(QGPL/RGZPFM)
MONMSG MSGID(CPF9803) EXEC(GOTO CMDLBL(ERROR4))
Paul
;
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Buck Calabro
Sent: Thursday, January 14, 2016 12:50 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: File Size / Reuse Deleted Records
On 1/14/2016 11:51 AM, Cyndi Bradberry wrote:
We are experiencing issues with files being created with either the default of 10000 records or *NOMAX. I personally don't like either, (no wars on this please).
What are best practices for file sizes ? How do you address the reuse deleted records option ? How do you address file full ?
I think it would be interesting if there were a set of best practices for all files. In my case, I have 'code' tables (like state abbreviation to full name) which never come close to 10k records, never have deleted rows, and never need attention. I also have transaction tables which grow like weeds, but rarely, if ever, have a deleted record. *NOMAX works great for us. Then I have master tables, which get many updates, few inserts and deletes. Every so often one of these will outgrow it's allocation and the operator gives it a '1' and tells the developers about it in case there's a problem.
For new tables, defined through SQL, we accept the defaults which reuse deleted records. Haven't had a pressing need to change that policy.
My thought is to build a file to contain the number of records and deleted records for each file at end of month. That will, over time give me an idea of how big things grow.
Look at the SQL catalogue table SYSTABLESTATS for some real time statistics.
With respect to end of month, I'd like to share my experience. I have transaction tables which grow continuously from January through December, then are reset to 0 rows in January. Were I to try to set these tables' sizes at any given end of month, they'd be wrongly too small 11 out of 12 months. The point being that in addition to the current month's statistics, you may want to store an 'all time largest'
statistic too. Along with the date that high tide occurred, so you can pin down why it was large.
I also would like to program to check for files nearing their stated capacity and bumping them by either a set amount or a percentage of active records and reporting that to me for review.
I don't do any processing by RRN, so I can set any table to reuse deleted records. The last time I had to manage a VTOC this carefully was on System/3 in the early 1980s.
--
--buck
Visit wiki.midrange.com and register for an account. Edit a page that helps you, and because it's public, you'll help someone else, too!
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
midrange.com
