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

Johnny Billquist bqt at softjar.se
Mon Jun 27 16:38:44 EDT 2016


On 2016-06-27 22:28, VAXman- at SendSpamHere.ORG wrote:
> In article <nkrqqm$fpl$1 at Iltempo.Update.UU.SE>, Johnny Billquist <bqt at softjar.se> writes:
>> On 2016-06-27 19:40, Bob Koehler wrote:
>>> In article <00B0B3EA.9F7943FA at SendSpamHere.ORG>,   VAXman-  @SendSpamHere.ORG writes:
>>>>
>>>> OK... So we should all toss fixed, VFC, VAR, STM and STMCF formats and use
>>>> STMLF exclusively.
>>>>
>>>> Again, the filesize (in bytes) CAN be had but they'll not mean what you want
>>>> them to mean to your protocol transfer.  Again, I don't see that as any VMS
>>>> problem;  I see it as a protocol limitation imposed by all of the *ixers out
>>>> there that have, parochially, defined these protocols RFCs.
>>>
>>>    Hm.   Windows stores text lines with CRLF separators, so that's 2
>>>    bytes meta-data per line of text.
>>
>> Well, with Windows it is not meta data, in that sense. It is actual file
>> content.
>>
>>>  VAR stores text with leaing
>>>    lengths in 16 bit words, so that's 2 bytes meta-data per line of
>>>    text.
>>>
>>>    Would seem to me that VAR isn't even a problem.  When you do the
>>>    conversion to the protocol's CRLF separators, you get the same total
>>>    bytes.
>>
>> If it was only that simple... But of course, it is not... :-)
>> With VAR files, if your record length is odd, it will be padded to an
>> even number before the next record starts, meaning you have one
>> additional byte not accounted for.
>> If you then also select that records should not span blocks, you might
>> actually get a lot of padding at the end of a block, which you normally
>> do not see or notice.
>> But doing the actual size calculations based on what meta data RMS is
>> storing is just not possible. :-(
>
> Correct.  Records in VAR format files are padded is the length of the record
> is odd to put the counter at a word aligned boundary.  In this case, the size
> computed with the computation I specified (that'd make C$STD_STAT() incorrect
> as well) could be off.

Yes! Finally we agree (I hope). The current stored data cannot be used 
to compute the size in bytes. The only way right now is to actually read 
the file.

Like I said, the code you showed for the C$STD_STAT() is equally useless.

	Johnny




More information about the Info-vax mailing list