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

[Johnny Billquist]

On 2016-06-23 23:17, VAXman- at SendSpamHere.ORG wrote:
> In article <nkherb$71o$1 at Iltempo.Update.UU.SE>, Johnny Billquist <bqt at softjar.se> writes:
>> On 2016-06-23 21:27, VAXman- at SendSpamHere.ORG wrote:
>>> In article <nkhctd$2us$1 at Iltempo.Update.UU.SE>, Johnny Billquist <bqt at softjar.se> writes:
>>>> On 2016-06-23 19:05, VAXman- at SendSpamHere.ORG wrote:
>>>>> 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.
>>>
>>> Why not?
>>
>> Converting is also reading it once, and then reading it again. Same as
>> just figuring out the size by reading it.
>
> No.  Because you asked about serving the file again and again.  The convert
> to RFM=STM is only once.  FYI, it's what you're doing if you are serving up
> a RFM=VAR file with your web server again and again and again.  You would be
> synthesizing the <CR>s and <LF>s over and over each access.

Indeed. I do "synthesize" CR+LF every time I read and feed the answer.
But that is done inline as I'm reading the file, and sending it.
You might as well argue why I read the file to service, as I already 
read the file the previous time I served it.


And yes, you could do the conversion, and then keep track of the fact 
that for this specific URL, you have a converted copy that should be 
used instead. This leads, as I pointed out in several replies, to you 
having to track when you have converted copies, checking that the 
original have not changed, and also more or less a doubling of disk 
space needed. Its possible, but it comes with a cost.

>> You only even get a potential gain from this, if you then cache either
>> the converted file, or the figured out size (I would actually just cache
>> the figured out size, since that takes way less memory.)
>
> How do you get the size on unix?  stat()?  Why can't you or won't you do the
> equivalent on VMS?

Because VMS do not have the information required? The whole reason that 
this thread exist...

>> Not to mention that converting everything to stream files is not always
>> what I want. Not to mention the issues with keeping track of, and
>> maintaining duplicates of files, and the amount of extra disk space this
>> might take. As mentioned in another response...
>
> If you want to serve a VMS file as a stream file, then why not maintain it
> as a stream file.  You've being argumentative for argument sake.  There's
> a way to get the file size in bytes but it'll be the real file's size and
> that'll depend on the file format(s).  A RFM=VAR, RFM=VFC, and RFM=STM can
> maintain all of the same *record* data but they will not necessarily have
> the same number of bytes in their files.  But, hey, I gave you the answer,
> but you don't or refuse to hear it.  Take a little time to learn about RMS
> file and record formats.  If that's too much, put your HTTP server over on
> *ix where you'll be happy.

Because the file is not a stream file to start with. The file already 
exists, and I want to serve it.
You are the one being argumentative for arguments sake.
If I have a file, I already have a file. Starting to argue about that 
you could have some other file, and then you could easily calculate the 
size of *that* file is a meaningless argument. I have the file I have. 
That is where this starts.

	Johnny