Change in disk space reporting in Directory command after OpenVMS 7.3.2

[Glenn Wolf]

After we upgraded from OpenVMS 7.3.1 to 7.3.2 on Alpha, we have seen a different behavior relating to disk space usage reported by Directory after Convert/RMS.

In 7.3.1 (and all prior versions we have used), after executing a Convert/RMS/FDL on an RMS ISAM file, we would see directory/size=all report two different numbers: uuuuu/aaaaa, where uuuuu was the number of disk blocks used in the file, while aaaaa was the number of blocks allocated (from the FDL file).

After upgrading to 7.3.2, and doing the same Convert/RMS/FDL, directory/size=all now reports the used value as the same as the allocated value. (aaaaa/aaaaa)

Is this by design, and if so, why? Or is it a bug?

We use this output to monitor how fast our ISAM database files are growing. Now we can only detect that file extents have been added (when aaaaa is larger than it was the last time we looked).

[Glenn Wolf]

Oh, we see the 7.3.2 behavior in 8.2 as well.

[Jon Pinkley]

Glenn,

Can you provide a example FDL file you were using?

Are the same disks being used as were being used before? What is the clustersize of the disk? Are you actually using the same FDL file, or are you recreating it with a script that uses analyze/rms/fdl and edit/fdl/nointeractive?

Hein is the expert on this, so I will let him respond. I do know there was a change in the bucket size calculations done by edit/fdl, it no longer being forces buckets to be at least 1 cluster (perhaps an integral multiple of clustersize).

Did you have something in your FDL that you were expecting to "pre-extend" the file?

Without a more concrete example, we can only guess.

[John Gillings]

Glenn,

The first number in the pair is the block containing the EOF. For sequential files, it can be interpreted as the number of blocks used. For indexed files, "EOF" doesn't make much sense, because the key chains can finish anywhere, and there is meta structure inside the file, including deleted space, so the EOF block can't be interpreted as "used space".

I think there were some changes in how RMS treated EOF in indexed files around the V7.3 time, which probably account for your observation. Maybe check the RMS release notes for V7.3-2?

[Hein van den Heuvel · Accepted solution]

The EOF value for an indexed file is meaningless. For example, if you create an indexed file with pre-allocated area-0 for data and seperate area-1 for index then even after adding a single first record, rms will write to the index near the end of the file.

RMS was intentionally changed to make EOF=ALLOCATED to stop some confusion in this area, but with that you lost the ability to have an indication of usage within the file. Of course it was only an indication, not an exact count, but still.

Anyway, it is not a bug but a feature.

Personally I tend to use a 'file of files' with file size 'goals' to see whether a file is growing unreasonably or not. (amongst various other checks like last convert date, index depth, global buffers and so on).

You could use ANAL/RMS/INT to look in the area descriptor for a precise indication of data block usage and growth indicators. Sample output:
Current Extent Start: 19, Blocks: 3, Used: 2, Next: 21

To get there, in a command file or perl script use:
$anal/rms/int x.idx
down
down
down area

hth,
Hein van den Heuvel ( at gmail dot com )

[Glenn Wolf]

Thanks to all who responded. I guess that we'll have to change our procedures for monitoring data growth.

One problem with the analzye/rms/int is that it won't work on a file that is open for write (as all of ours *hopefully* always are). We can indirectly monitor the copy that we keep updated continuously, but we can only check once per day when we stop the update to backup the files.

Our files aren't complex, but they can get pretty big (55 million blocks per). We are no doubt more sensitive than we need to be about controlling extents (we preallocate space via FDL parameters after quarterly convert/rms to minimize extents) with current SAN storage and XFC.

[Hein van den Heuvel]

>> One problem with the analzye/rms/int is that it won't work on a file that is open for write

Yeah, I've requested a /SHARE for ANAL/RMS before, and have just been asked for inputs for an RMS wishlist so I'll add that again.
Should be easy, as long as the users accept the caveats of looking at a live file. Your case is a perfect example where interlocking is of no concern.

You can try my FDL$GENERATE tool from the OpenVMS Freeware V6 [RMSTOOLS] for shared FDL info.
It shouldn't be too hard to cook up a dedicated program to report area-0 allocation information either.
Contac me if you need help with that.

Cheers,
Hein van den Heuvel ( at gmail dot com )