Re: [Simh] Simh Digest, Vol 147, Issue 38

2016-04-20 Thread Johnny Billquist

On 2016-04-21 00:24, Larry Baker wrote:

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.


The icing on the cake is that C-Kermit can actually connect over telnet, 
so that side is also already solved. If your simh instance have a serial 
port, and it is mapped to a telnet port (something that simh supports), 
then run C-Kermit on a Unix box, and telnet into simh, and you have your 
kermit connection all set up.


If someone wants to see this in action, install C-Kermit on your 
machine, and start it. Then telnet to mim.update.uu.se (in kermit), and 
login as GUEST with password GUEST. This is not a simh instance, but no 
matter. It is an RSX system, it has Kermit-11 installed, and you are 
connected to something that looks like a serial port on that machine. 
Start Kermit-11, give the command "SERVER", and then return to C-Kermit 
prompt, and try something like DIR.


Works like a charm.

Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Simh Digest, Vol 147, Issue 38

2016-04-20 Thread 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
ba...@usgs.gov



On 20 Apr 2016, at 3:00 PM,  
 wrote:

> Date: Thu, 21 Apr 2016 00:57:05 +0300
> From: Sampsa Laine 
> To: "Hittner, David T (IS)" ,
>   "simh@trailing-edge.com" 
> Subject: Re: [Simh] Way out idea for simh
> Message-ID: <3e1ee968-7be2-487c-ba38-b1bb8f395...@mac.com>
> Content-Type: text/plain; charset="utf-8"
> 
> 
>> On 21 Apr 2016, at 00:28, Hittner, David T (IS)  
>> 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 , and I was having problems with file transfers to a 
>>  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
> 
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh