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

[VAXman- at SendSpamHere.ORG]

In article <nkr95m$vvh$1 at Iltempo.Update.UU.SE>, Johnny Billquist <bqt at softjar.se> writes:
>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...

https://www.youtube.com/watch?v=2LScoi7pK68

It does!  It may not be there jumping up and down waiving a flag and screaming
"here's the byte count" but it's readily and easily obtained; however, as I've
stated time and time again, it may not mean what you want it to be.  




>>> 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.

Then, serve it.  It's the fault of the recipient that it can't understand it.
If it can't, then you need to convert it (as you've said, you synthesize the
necessaries) and thus, you need to synthesize an appropriate byte count.



>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.

It's hopeless...  

I suppose that the only thing that would satisfy you would be to maintain a
byte count of every possible record format when the file's records are added
or updated.  I've spent at least 5 years with my head in the bowels of RMS on
VMS and I could probably wedge that in there for you but why?  I know why you
say why but it serves no VMS, file system or RMS purpose.  

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

I speak to machines with the voice of humanity.