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

[VAXman- at SendSpamHere.ORG]

In article <nl3ffj$ibt$1 at Iltempo.Update.UU.SE>, Johnny Billquist <bqt at softjar.se> writes:
>On 2016-06-30 17:15, VAXman- at SendSpamHere.ORG wrote:
>> In article <nl35rj$v6l$1 at Iltempo.Update.UU.SE>, Johnny Billquist <bqt at softjar.se> writes:
>>> On 2016-06-30 14:48, VAXman- at SendSpamHere.ORG wrote:
>>>> In article <nl0k69$nov$1 at Iltempo.Update.UU.SE>, Johnny Billquist <bqt at softjar.se> writes:
>>>>> On 2016-06-29 15:45, VAXman- at SendSpamHere.ORG wrote:
>>>>>> In article <nl0gec$fke$1 at Iltempo.Update.UU.SE>, Johnny Billquist <bqt at softjar.se> writes:
>>>>>>> It is not the size of the file on the disk. Simple as that.
>>>>>>
>>>>>> You're too thick.
>>>>>
>>>>> Calling an apple a pear won't make it so.
>>>>>
>>>>> What you try to talk about is the size of your data on the disk, which
>>>>> is not the same as the size of the file on the disk.
>>>>> And we have already established that figuring out the size of your data
>>>>> on the disk is also not doable in VMS.
>>>>>
>>>>> You can call ma any number of names, if that makes you happier. But at
>>>>> the end of the day, nothing have changed. And starting to call names is
>>>>> really not much of a technical argument.
>>>>
>>>> Well, I know you don't want to go beyond your precious "C" but, since you do
>>>> seem to be implying sequential files, you might find some solace in the RMS
>>>> XABITM XAB$_FILE_LENGTH_HINT.  I can show you how to invoke the RMS from "C"
>>>> if you request.
>>>
>>> Your assumption on my C preference is incorrect. I know C. Don't mean I
>>> don't know other languages, or that C is my preferred language. It's a
>>> language that sometimes is useful, but if I can choose, I'll take
>>> MACRO-11 thank you very much.
>>>
>>> And at the end of the day, your file have still taken the same amount of
>>> space on the disk, no matter where your EOF pointers point to. And
>>> unless VMS works differently than RSX (which I seriously doubt), the
>>> file size, as used on the disk, is something kept track of by the ACP,
>>> which is what deals with the actual file.
>>> RMS is the layer that cares about the EOF pointer. But RMS do not deal
>>> directly with the disk, but is actually just dealing with the file, as
>>> given by the ACP. So your EOF pointer is not even something the actual
>>> file level layer is even aware of. Now, I know that the water is much
>>> more muddled on the VMS side. In RSX the separation between these layers
>>> are very simple and clear, and you don't even have to use RMS when you
>>> access your file. You can do your IO requests directly to the ACP, if
>>> you want to.
>
>[...]
>
>I'm not even sure what you are trying to say or prove anymore.
>
>Your LOGIN.CMD have 48 allocated blocks. That's the size your file take 
>up on the disk. You might fight and deny it all you want. Won't change a 
>thing. (And counting that in bytes is 24576 bytes. No more, and no less.)
>
>Furthermore, the number of byte actually in that file is something you 
>cannot tell me without reading through the file. And with that "number 
>of bytes", I am referring to the number of bytes you would read, if you 
>were to do sequential $GET on the file until you get an EOF error, and 
>you sum together the lengths of all the records $GET gave back to you.

Where did I read through the file?  OK.  I did a SEARCH to show you what the
XAB$_FILE_LENGTH_HINT would give you without reading the file.



>Which is what I've said all along, and which you have also agreed is the 
>case.

I hve NOT agreed.  Read the post to which you have just replied to and have
elided all the proof.



>So, why do you continue to write a lot of stuff about this. None of it 
>will change the two facts above, no matter how much FUD you throw up.

What fear?  What uncertainty?  What doubt?

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.