[Info-vax] RMS internals?

[Michael Moroney]

Howard S Shubs <howard at shubs.net> writes:

>In article <0037589e$0$28455$c3e8da3 at news.astraweb.com>,
> JF Mezei <jfmezei.spamnot at vaxination.ca> wrote:

>> If your client trasnfered in binary mode, you would have raw data with
>> CR-LFs terminating records.  (or whatever line termination sequence
>> windows uses). It would be easier to parse since there would be no RMS
>> interpretation of the data.
>> 
>> Binary/image mode usually results in a file created on VMS with fixed
>> length 512 byte records (aka: 1 record per block) and no record
>> attributes. So when you read the data, you get the data uninterpreted by
>> RMS.

>Yes, that's why I asked them to get me a file transferred in binary 
>mode.  I wanted to see what it'd look like to me.  Fixed length 512 byte 
>"records" aside, I'm not sure I want to play the "what terminator are we 
>looking for today" game.  Coming from Windows, that's a pretty easy 
>game, I'll grant you, but I want to keep this as general as I can.

I have to deal with similar problems once in a while.

FTP in ASCII mode will do some interpretation as you have mentioned.  If
there is something that looks like a record terminator in the middle of a
record, it'll split the records in two, as well as doing things like
<CR><LF> -> <LF> in stmlf output files.  If you can guarantee that there 
is nothing that looks like a record terminator in the middle of a record,
you'll be OK except if a new version of TCP/IP software causes a change
in the behavior you saw (records split into one the max size the second
with the remainder) you'll be OK.  If you transfer it in binary, you'll
get the bits exactly as they exist on the remote end although the file
format won't usually be correct (VMS->VMS passes extra info and will 
recreate the file with proper RMS attributes) so you won't get fooled 
by a stray <CR><LF> in the middle of a record.