On 2012-12-31 17:50, Brian Schenkenberger, VAXman- wrote: Johnny Billquist <bqt at softjar.se> writes: (Or rather, Emacs is lying to VMS, and VMS is buying it.) The Emacs for VMS post is ancient (neolithic) history. Who knows what's being told to the file system when a file is created, updated and closed. Yeah. And I think therein lies the lie. However, when feeding that file over DECnet, the result looks ugly, so the FAL in VMS isn't totally falling for the lie. :-) FAL will open the file based upon the file attributes of the file and it will then attempt to digest it with those file attributes to transfer it over the wire. Without a corresponding set of file attributes on RSX, it is possible that it's RSX that is choking. Try logging into the VMS box which has this file and dump it: $ DUMP/RECORD <the-file>/OUTPUT=THE_FILE_RCD.DMP $ DUMP/BLOCKS <the-file>/OUTPUT=THE_FILE_RAW.DMP ...and then, make it available here so that I can see its layout. I DO not believe that VMS RMS "lies"; especially, after four years of work in it! I should point out that it worked just fine transfer the file to RSX. What happened was just that each line had an LF at the end, and then of course each line has the Carriage return attribute. So, typing the file in RSX, I see it just fine, but with an extra LF at each line. Totally expected, based on what existed in the file. So, RSX didn't choke. It got the file, with linefeeds. However, if I transfered the file using block mode, which shoudn't touch anything inside, I can see that the "original" file, as far as I can tell, really is the text, separated by just LF for each line. So obviously, when VMS serves the file, it considers the LF to be record separators, even though the file is Stream_CR. And it's not stripping the LF away when transferring. This all sounds very reasonable, with the possible exception of how VMS reads out records from a Stream_CR file. If Bob could do dumps of the original file, it would be cool to look at to just confirm what I'm writing. Johnny