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

[Johnny Billquist]

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.

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

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.

	Johnny