[Simh] Simh Digest, Vol 147, Issue 38

[Larry Baker]

What about file systems that have multiple metadata streams, like NTFS?  (Multics?  I know, not a SIMH machine.  But, the argument is to make a "universal file transfer tool".)  One stream for ACLs, for example, another for Macintosh AFS (gone now), any number of other streams you can use yourself.  I supposed each one could be a ._blah file, assuming that is a legal file name.  If one system uses numbers for metadata streams and another uses names and yet another uses different numbers or names, how are you planning to match them up?

Binary files = bad idea

Text files (including ASCII<->EBCDIC<->BCD) = Kermit

Assuming the machinery of SIMH already supports connecting a serial port to an IP socket, all you may have to write is something to bridge that socket to Kermit on your client machine, ala a telnet data stream so Kermit sees it as a telnet server.  Some (all) SIMH emulators already support a telnet session to a serial port.  Then your SIMH system reads and writes to the serial port using its native device support, and you—human—cut and paste into the Kermit window on your client machine.  You don't have to run a Kermit on the SIMH emulated machine; the SIMH machinery captures serial data and send/receives it for you.

I agree with Johhny Bilquist on this one: I don't see any advantage in reinventing what already works.

Larry Baker
US Geological Survey
650-329-5608
baker at usgs.gov



On 20 Apr 2016, at 3:00 PM, <simh-request at trailing-edge.com> <simh-request at trailing-edge.com> wrote:

> Date: Thu, 21 Apr 2016 00:57:05 +0300
> From: Sampsa Laine <sampsa at mac.com>
> To: "Hittner, David T (IS)" <david.hittner at ngc.com>,
> 	"simh at trailing-edge.com" <Simh at trailing-edge.com>
> Subject: Re: [Simh] Way out idea for simh
> Message-ID: <3E1EE968-7BE2-487C-BA38-B1BB8F395621 at mac.com>
> Content-Type: text/plain; charset="utf-8"
> 
> 
>> On 21 Apr 2016, at 00:28, Hittner, David T (IS) <david.hittner at ngc.com> wrote:
>> 
>> If Kermit does not work on SIMH emulated RTE-6/VM, but works on the real hardware, then I’d say there’s a BUG in the emulator that needs fixing. Derp.
>> Ø  Kermit cannot be made to work reliably on RTE-6/VM under simh.
>> Ø  At least I was never able to make it work.
>> Ø  Not to mention that trying to use an emulator other than QCTerm (which doesn't do Kermit) with RTE is a major PITA.
>> Ø  I used Kermit extensively on real RTE systems to transfer files to a variety of systems.
>> 
>> Another option is to start a file creation in the emulation from the serial port and use a terminal emulator to cut and paste (slowly) the ascii or hexified file in for you (hopefully with a windows cut/paste), or type(cat) the file to the terminal emulator and select/copy the text out to a host file. Attachmate has worked well for me as a slow cut/paste terminal emulator. Hexifying binaries is a tried-and-true serial copy method when flow control is non-existent or suicidal, and there are quite a few tools to hexify/unhexify data streams.
>> 
>> There’s also lot of tools available for file conversion (mangling), and Kermit is supported on many platforms. Look at the older Kermit-16 and Kermit-32 if you want a simpler Kermit.
>> 
>> If you want to write a universal file transfer tool for ALL of the hosts and emulators SIMH supports, AND write in the OS support drivers for it on ALL of the emulated OS’s, then go for it. But it’s a lot more work than you might think, for very minimal gain.
>> 
>> If it was <me>, and I was having problems with file transfers to a <specific> emulator/OS combination, I’d look to find a solution for that specific platform problem, and not try to solve all of the SIMH host file transfer problems with a universal solution. You’re looking for a universal solution to 50+ years of device and filesystem incompatibility. Most people agree that Kermit is the most universal file transfer solution available.  :-S
>> 
> 
> I still like the idea of a standardised protocol for moving files + metadata in/out using SOME mechanism (e.g. serial port) that is mapped to a directory on the host OS.
> 
> Whether people then want to actually implement the tools for the guest OS depends on the need for them.
> 
> But one standard, simple protocol would be nifty..
> 
> sampsa
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20160420/47106702/attachment.html>