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

[Johnny Billquist]

On 2016-06-23 19:05, VAXman- at SendSpamHere.ORG wrote:
> In article <nkh313$ekh$1 at Iltempo.Update.UU.SE>, Johnny Billquist <bqt at softjar.se> writes:
>> On 2016-06-23 18:06, VAXman- at SendSpamHere.ORG wrote:
>>> In article <nkgspt$rm$2 at Iltempo.Update.UU.SE>, Johnny Billquist <bqt at softjar.se> writes:
>>>> This whole thread came about because some people pointed out that exact
>>>> file sizes, to the byte, sometimes were wanted. And then it's been a
>>>> thread of "why?". And when I give an example of why, it becomes a thread
>>>> of "why?".
>>>>
>>>> Yes, I know VMS couldn't care less. RSX also couldn't care less. Me,
>>>> writing an http server (as well as an ftp server), do care. And doing
>>>> these things, which many people consider to be pretty basic tools that
>>>> all systems should have, is a pain because the file system do not have
>>>> this information.
>>>>
>>>> Yes, there are solutions. They are costly. Could there possibly be a
>>>> point in adding this information, if it can be done at a low cost?
>>>>
>>>> You are just putting your head in the sand and saying that since it's
>>>> not there, we don't need it.
>>>
>>> Why pay for it when you don't need it?  Pay for it when you do!
>>
>> Which, for a web server, is every time a document is requested, which
>> might mean a dozen requests for a single page. And that is just one
>> example. And for a 10M document, calculating the size every time is
>> pretty costly... Reading through 10M to find the size, and then read
>> through it again, to deliver it. Color me not-excited.
>
> Again, that's not a VMS problem; it's your/the protocol.  Perhaps, instead
> of about it complaining here, you should complain to the IETF. ;)

I'm not complaining. I'm merely pointing out that sometimes the file 
size of the actual content, in bytes, is useful to have.

> VMS moved files over the network without having to know the precise number
> of bytes it has to move before doing so, so there could and there should
> and there are alternative ways this can be accomplished without knowing a
> count beforehand.

Yes. It all depends on the protocol, as well as on what features you 
want. VMS to VMS is a rather special case. In a heterogeneous 
environment, things always becomes more complicated. But I guess you 
don't care about talking to anything except other VMS boxes. Why do you 
even use TCP/IP???

> *IF* you need to transfer your files as you state, then choose your file's
> record formats appropriately and you should be able to compute the file's
> byte count from readily available info. ;)  But don't force an unnecessary
> burden on my files because you need some data that's of no consequence to
> me.

You already have various unnecessary burdens on your files because of 
other design choices, which sometimes will give you benefits, and at 
other times are just a cost.

And if I transfer files, I can't choose the format. The files already 
exist, and I'm supposed to transfer them, not create them.

> HP Alliance One distributes PAKs as a text file that is stream (chock full
> of <CR>s and <LF>s).  I'm supposed to execute this to install the Alliance
> One PAKs.  Some people (on VMS) find this a nuisance because of the <CR>s
> and <LF>s littering the data (because it's delivered via HTTP from HP's A1
> web site) cause DCL to complain.  I simply change the file's attributes to
> RFM=STM and all's well.  You, too, could convert your files to RFM=STM and
> then, your prayers have been answered.  What YOU want to transmit via HTTP
> is all right there in the file and you should be able to compute the file
> size as well.  But, it's so much easier to fault VMS, its file system, and
> RMS because it's not understood.

Sorry, but that is not the correct answer.

	Johnny