RMS indexed file optimization, which qualifiers ?

Management of storage subsystems: SAN, volume shadowing, logical disks, file systems, and more.
Post Reply

Topic author
Posts: 1
Joined: Tue Sep 14, 2021 7:41 am
Reputation: 0
Status: Offline

RMS indexed file optimization, which qualifiers ?

Post by fossman » Tue Nov 09, 2021 7:17 am


I'm curious about the best way in a generic procedure used during BATCH procedures to generate an Optimised FDL file for RMS INDEXED files via the command EDIT/FDL/NOINTER fdl ANALYSIS=xxx /out=yyy that will later be used to convert the file in the same procedure and whether using /SCRIPT=OPTIMIZE or /EMPHASIS=FLATTER_FILES is better

I can find limited documentation on the differences and I'm sure I've seen Hein make a recommendation in one of his presentations that in general flatter RMS indexed files are better if you don't have any evidence indicating otherwise


Active Contributor
Posts: 25
Joined: Fri Dec 25, 2020 5:20 pm
Reputation: 0
Status: Offline

Re: RMS indexed file optimization, which qualifiers ?

Post by hein » Tue Nov 09, 2021 11:32 pm

Don't worry about creating a great automatic optimization environment.
It's unlikely to be noticeable.

Flatter files are still better though: fewer locks, better caching.

But it is not nearly as critical as 40 years ago when EDIT/FDL/OPTIMIZE was designed.
Just throw more buffers at it, preferably global but why not local as well.
Tell me about your global buffer choices - if you cannot answer, then don't bother with other tuning.

Instead of focusing on a generic script for all, your time is probably better spend in trying to figure out your hot-files with whatever tool you might have.
Without tools just SHOW MEM/CACHE =(VOLU=xxx,TOP...) for TOPQIO and TOPHIT for top volumes.
Just tune the top 10 files to begin with and see if anything more even matter after those are dealt with.
Use SET FILE/STAT/SHARE on a couple of 'suspect' files.

Absolutely do do you converts 'once a year whether it needs it or not'. That's good, required practice.
But don't worry about the FDL too much.
just run edit/FDL/OPTIME just once, then take the FDL and post-edit it by adjusting the allocation to cover the next year, and round up bucket sizes big time. 17 suggested? Make it 32.

Edit/FDL/OPTIMIZE will try to figure out whether 18 block buckets will keep the index down to 3 level where 17 might not.
I tell you, it matters none - pick 24. or 32, or 42 to be on the safe side and be done.
Back it in day it absolutely mattered ... at 2MB/sec, and 50 IO/sec for a good disk.
What can your IO system deliver now? 200MB/sec and 5000 IO/sec?

So the only difference you can make is to avoid IO's not to make them marginally faster.
You avoid IOs by having larger caches, more buffers and get rid of stupid stuff like extending files all the time.


Post Reply