This is very bizarre. I worked (peripherally) on MS-DOS Kermit and (extensively) on VMS C-Kermit.
The whole reason the Kermit protocol was invented was to get around various problems with moving files from system A to system B, which might have a different character set, some box in the middle that either discarded or generated control characters, etc. In binary mode, what you get out should be what you put in, aside from limitations on the receiving end (for example, some operating systems don't keep track of the exact file size in bytes, but only in disk blocks - but that should not be a problem with your RT-11 files). 8-N-1 and FILE TYPE BINARY on both ends. It is possible that the serial driver is forcing the port to 7-bit mode (clearing the high bit), but I'm pretty sure Kermit knows about that sort of thing and has a way to deal with it.
Wikipedia claims "The Kermit protocol supports text and binary file transfers on both full-duplex and half-duplex 8-bit and 7-bit serial connections in a system- and medium-independent fashion, and is implemented on hundreds of different computer and operating system platforms. On full-duplex connections, a sliding window protocol is used with selective retransmission which provides excellent performance and error recovery characteristics. On 7-bit connections, locking shifts provide efficient transfer of 8-bit data." (Note that your RT-11 implementation probably doesn't do sliding windows, but that just means slower transfers, not broken ones.)
fdc and I worked on a C-Kermit extension that let Kermit transfer arbitrarily complex files - our test case was sending an RMS indexed file with multiple keys and with a journal attached, from VMS -> MS-DOS -> IBM VM/CMS -> DECsystem-10 -> VMS and having it come out intact on the far end VMS sytem.
Back to your issue at hand, I assume you're limited to the tools you have on that system already. Is there an RT-11 utility that dumps all of the blocks in a file as hex digits? You could then just ship that out the serial port and use a program on whatever system you have on the far end to re-constitute it as binary.
Thanks for your feedback.
Just so you know, I have almost 50 years experience dealing with RS232 communications links, and design both analog and digital hardware and write software in 20+ languages, including hardware and software flow control on com links. So not a newbie.
I've spent 80 hours trying to get this simple kermit-11 2.18 connection to my PC to preserve this 20mb hard disk but bit 7=0 on all files.
This Kermit-11 came with this machine and I'm sure it worked for the original users.
This DEC PDP11/23 ran flawlessly transferring 503 files over 6 hours, only to find out all files are bit 7=0.
My current suspicion is that the FTDI USB to serial adapter is somehow mis-engineered to zero the 7th bit regardless of the setting.
If I set parity to space then it transfers without error messages but the data still has bit 7 cleared.
This made me think kermit was smart and converting 8 bit bytes to 2 ascii hex characters or frame shifting, but apparently not.
I've tried every port setting, on both sides, dug into the driver properties on PC Windows side, still the same thing.
I just got through using realterm in Hex display mode and did a TYPE DIR.SAV and all bytes have 7th bit cleared.
I doubt this is right for a binary file like DIR but someone correct me if I'm wrong.
I've double-checked the jumper setting on the serial I/O board on the PDP11 -- baud=9600, stop=1, parity=none, data length=8
And those parms work fine with any dumb terminal or emulator on my windows machine.
I am stumped.
