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

[VAXman- at SendSpamHere.ORG]

In article <nks6g5$dk1$1 at Iltempo.Update.UU.SE>, Johnny Billquist <bqt at softjar.se> writes:
>On 2016-06-27 23:29, VAXman- at SendSpamHere.ORG wrote:
>> In article <nks2sl$4ce$1 at Iltempo.Update.UU.SE>, Johnny Billquist <bqt at softjar.se> writes:
>>> 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.
>>
>> But it IS the file size; it's not the recorded data size.  You DON'T WANT the
>> file size -- which the computation provides; you want the recorded data size
>> -- which that computation does not necessarily provide you.
>
>Well, what do you mean by file size then? The number this computation 
>gives is neither the number of bytes used on the disk, nor the number of 
>bytes I would get if I read the file.

It *IS* the number of bytes used on the disk.  Explain how it is not.



>The number is in fact just an approximation of the number of bytes I 
>would get if I read the file.

That can be true but it *IS* the number of bytes consumed by the file.



>Sometimes approximations can be acceptable, at which time this algorithm 
>works, at other times approximations are not acceptable, in which case 
>this number is useless.
>
>Because, as I said, it don't really represent any real number that tells 
>me anything about the file.
>
>> In general, your desire provides nothing that'll make VMS work any better, so
>> why does or should VMS have to maintain it.  *ix doesn't either because it's
>> counting the <LF>.
>
>VMS do not work any better because it tracks the number of times a file 
>have been modified either, and yet VMS do track that. Why should it, then?
>Unix does give me a number I can use sometimes. The only time it is not 
>usable is when I want to give something back in a network standard text 
>format, and the file is in the Unix standard text format.
>Which is already much better than what VMS does today. And if VMS now 
>where to be improved here, why not make it better than Unix, instead of 
>just using Unix as some reference?

Performance metrics are useful.  The may not make a file work better but they
can be very useful to make use of the file better.  One of the things seen by
RMS CDC was programs doing $OPEN/$UPDATE/$CLOSE for every file operation.  If
knowledge can be derived from observation, things can be done to correct and
or streamline operations. 
-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.