On Nov 17, 2014, at 11:08 AM, Cory Smelosky <b4 at gewt.net> wrote: On Mon, 17 Nov 2014, Paul_Koning at Dell.com wrote: On Nov 15, 2014, at 9:17 PM, Johnny Billquist <bqt at softjar.se> wrote: ... $ copy 9.1::sys$specific:[decnet]k11.tsk k11.tsk Node: 9.1 User: csmelosky Password: System Password: ?NFT -- Bad RFM field in FAB What a helpful error message. ... As for the error message, knowing RMS helps. FAB is the File Access Block. RFM is (if I remember right) Record Format. Probably RSTS/E cannot just grok the record format of that file. You can give switches to NFT under RSX at least, to tell what the format should be when copying... RSTS uses RMS for this sort of thing, and yes, it certainly should understand RSX RMS files without further help. I wonder if RSX is sending something bogus based on the fact that the remote system is RSTS. Hard to say without seeing what is sent. 9.1 is VMS. It might be worth experimenting with block or record mode to see if that helps. Executables are fixed:512 files so it doesn?t make a whole lot of difference which mode is used. Another possibility might be to copy RSX to VMS and then VMS to RSTS. FTP to VMS (image mode), VMS to RSTS is what game the error! Oops, I misunderstood, I thought the file was coming from RSX. What does VMS claim the RMS attributes are for that file? If it started out with FTP, it may be something odd, like stream. I don t remember how to query RMS attributes on VMS, but I assume there is a way. An alternative way to transfer files that give NFT trouble is to back then up, then send the backupset. RSTS can read VMS backupsets (if you have a sufficiently new RSTS V9.0 or later, if I remember correctly). Backupsets are fixed record sequential files, which in general should copy just fine. paul