RMS file rebuild

[Jefferson Humber]

We have some RMS files in our application, which over time get flabby and require maintenance.

We currently perform the following periodically to maintain optimal performance.

$ CONVERT/FDL=file.fdl fileold.rms filenew.rms
$ DELETE fileold.rms
$ RENAME filenew.rms fileold.rms

Anybody know of an easier way of doing this ? I could keep the filenames the same and use PURGE instead, but was wondering if there is a single command to streamline the operation.

Cheers,

J

[Ian Miller.]

I guess you could try having the same name imposing a file version limit of 1 but do you really want to do this. Having the previous (unconverted) version of the file provides additional backup.

[Joseph Huber_1]

1. put the commands in a DCL command-file, define a foreign command to execute the command-file, or put the command-file into DCL$PATH directory(-ies).

2. as a oneliner:

PIPE CONVERT/FDL=file.fdl fileold.rms filenew.rms && DELETE fileold.rms && RENAME filenew.rms fileold.rms

[Hein van den Heuvel · Accepted solution]

>> Anybody know of an easier way of doing this

I woudl actually suggest to make it a little more complicated. Serious.

IMHO you really want to keep the old version in place during the convert (as you do), then rename current to old, and new to current (in that order).
Why not leave the old file behind for a cycle? So delete the old-old just before the new convert. That way you will not need a backup on the day of the convert, and you will always be able to check back to analyze any problems.

You want to add a /STAT to the convert.
This will deliver you a record count. That can server as a sanity check, but more over it can serve as input for and EDIT/FDL/NOINTERACTIVE tuning session on the FDL file being used.

Has that FDL file been tuned/reviewed recently? (ever?)

This would all be pretty normal. Now you might have a special case. For example, you may have a work/queue file that gets down to 0 records at then end of the day. In that case there may be other options.

Maybe you want to share a little more about the size and usage of the file(s) and a hint as to what constitute 'flabby'? (One assumes it mean many more block then strictly needed to hold the data).

If performance is a concern, and not just looks, then check out 'rms_tune_check' in the rms_tools directory on the VMS Freeware.

Regards,
Hein.

[Jefferson Humber]

Joseph - The PIPE is cheating IMOH, I did think of that already ;-)

Hein - Yes you are correct, the files grow over time. They start off at 300 blocks, but over time can grow to 40000 blocks. They are used to hold sequence numbers e.t.c So never get any bigger in terms of rows, they just get updated alot.

I will add the /STAT, sounds good to me.

Jeff

[Hein van den Heuvel]

>> They start off at 300 blocks, but over time can grow to 40000 blocks.


Well, you may want to investigate that a little further. That is possibly avoidable.

And if it is not avoidable, then you may want to accomodate by already preallocating say 20,000 blocks and an extent of 5,000.

You MIGHT be a candidate to use a daily CONVERT/RECLAIM. In general though I find a straight convert preferable.

Admittedly knowing nothing about your specific usage or file attirbutes here is a WAG: Experiment one convert with the maximum buckets size (63). Some growth behaviours can be avoided/minimized doing this.

Also, for more help be sure to gather and present us with ANA/RMS output with stats for a file just before the convert.

Regards,
Hein.

[Antoniov.]

Hi Jeff,
last post of Hein sounds good!
- Choice if you prefer quick access or save space on disk.
- Create a preallocate file.
- Use big extension quantity (about 1/8 of preallocation).
Remember you can manipulate some parameter of fdl like these.
- Bucket size: if read many and write little use a big value (e.g. 63); big values increase risk of lock.
- Data_fill: it's the percentage of filling bucket size. If write and rewrite many, use little value like 50.
- Index_fill: same for indexed keys.
- Data_record_compression: enable compression of record.

Antonio Vigliotti

[Wim Van den Wyngaert]

If you have the diskspace, I would even take extent size equal to initial allocation or allocate initially twice the current allocation. Beter prevent fragmentation than repair it.

12 years ago, we had a program that generated the fdl based upon the current fdl info and the number of records. Simply to save us the trouble to look again and again at the fdl.

Wim

[Peter Quodling]

I would agree with Hein (hey Hein - long time...) - investigate the nature/specifics of the file that you are dealing with.
Some years back I had to fly to another country to fix a "mission critical" performance problem. As I recall, the solution, was a file rebuild and tune, and changing their open's from fopens to actually include FAB/RAB values. Took 2 hours, ran like a rocket, and I spent 3 days on the beach waiting for the next flight home...

Also take advantage of "Versions" in the file system. Many is the day, that this has given a quick recovery.

Peter