[Info-vax] Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT)

[Paul Sture]

On 2016-06-18, Stephen Hoffman <seaohveh at hoffmanlabs.invalid> wrote:
> On 2016-06-18 08:54:54 +0000, Paul Sture said:
>
>> cf VMS only storing the block sizes of files rather than the number of 
>> bytes; this can be problematic for utilities ported from a system which 
>> has an easy/cheap way to supply the exact size in bytes.
>
> See the XAB$W_FFB first free byte value, for those file formats that 
> aren't block-storage-oriented.

I've always understood calculating sizes from the furst free byte value
to be an approximation.  Here's a simple example:

$ create x.x
A
BB
CCC
^Z
$ dump/dec/byte/width=80
Virtual block number 1 (00000001), 512 (0200) bytes

  66  66   0   2   0  65   0   1 ..A...BB      0
  -1  -1   0  67  67  67   0   3 ..CCC...      8
   0   0   0   0   0   0   0   0 ........     16

Note that the record size fields get word aligned, as does the
EOF marker.  Thus adding up the record sizes, plus 2 bytes for
the record size doesn't accurately reflect the actual bytes
consumed.

And IIRC, further padding can occur at a block boundary, even where
records can span blocks; I'm thinking of VFC records here but I'm pretty
sure I encountered longword padding, possibly to keep the record size
field and contents together.

> With OpenVMS, there's also the fairly user-visible distinctions among 
> the file user content size in bytes, the file storage being used for 
> the user data in blocks/sectors, and the total storage allocated to the 
> file in blocks/sectors due to pre-extending and the rounding up 
> inherent in the cluster factor.  Then there's the metadata embedded in 
> various of the common formats, even within the various sequential 
> formats.   Unix doesn't default to anything like VFC sequential files, 
> after all.

According to:

<http://h71000.www7.hp.com/doc/731final/4523/4523pro_015.html#index_x_697>

both XAB$L_EBK and XAB$W_FFB Field are "meaningful for sequential files
only" (caveat, the above URL points to the V7.3-1 documentation)

> Do you count that metadata in the file size, or not? Arguably no, but
> it's inherently part of the file on OpenVMS and not at all easy to
> exclude — whether VFC or the indexed file structures or otherwise.

Tricky.  If you are looking at the output of TYPE, then the record
attributes (e.g. Record attributes Carriage return carriage control)
make a difference to the output.

> Not that OpenVMS APIs and the OpenVMS docs even particularly lend 
> themselves to presenting this or related information, either.   Having 
> some decently-designed OO methods for retrieving this and other 
> metadata would changes this into something rather easier to deal with; 
> less glue code than is involved dredging through XABs.

Having done this stuff from COBOL, I emphatically agree.

-- 
There are two hard things in computer science, and they are cache invalidation,
naming, and off-by-one errors.