[Simh] RSTS/E 10.1-L and Paper tape

[Larry Baker]

On 6 Jan 2016, at 6:03 PM, <simh-request at trailing-edge.com> <simh-request at trailing-edge.com> wrote:

> On Jan 6, 2016, at 4:00 PM, <simh-request at trailing-edge.com> <simh-request at trailing-edge.com> wrote:
> 
>>> 1. DECnet.  NFT will use the DAP protocol to do file transfer; if you have a compatible DAP implementation at the other end that would work.  DECnet/Linux can do this, I believe.
>>> 
>> If you can find it DEC PATHWORKS apparently still works on Windows XP,
>> of course you'll need to fire up a VM for it in most cases; and
>> DECnet/Linux has basically become unsupported.
> 
> 
> Don't dismiss DECnet/Linux as a viable solution.  It's true the DECnet/Linux community is small and the main players of long ago are gone.  But, that doesn't mean it does not work.
> 
> I have been a long time user of DECnet/Linux, mainly on CentOS.  We use it for backups over DECnet mostly, and file exchange.  Stand-alone backups work just fine.  When the disks on my last CentOS version went belly up, I decided instead of a dedicated DECnet NAS, it was a better idea to use our NFS disk farms for storage.  I built a couple DECnet/DAP-to-NFS gateways using a Marvell SheevaPlug "PlugPC" with a Kirkwood ARM SoC (no FPU).  I am at home at the moment, so I cannot tell you what Linux kernel I used.

[root at sheeva ~]# uname -a
Linux sheeva 3.16.6-decnet-ARCH #1 PREEMPT Thu Oct 16 20:21:16 PDT 2014 armv5tel GNU/Linux

My notes at the time I built the DECnet/DAP-to-NFS gateway say:

The latest Linux longterm 3.16 kernel is 3.16.6 (https://www.kernel.org).  The last Arch Linux ARM Kirkwood-specific Linux 3.16 kernel was for 3.16.6 on October 16, 2014, https://github.com/archlinuxarm/PKGBUILDs/commit/8be533de52d44d39b2b12999e979d4d377f5e2e5.

I had to patch the kernel config file to add DECNEt support and the decnet driver file dn_route.c to call dst_metric_raw() instead of dst_metric().

> I haven't checked on them in a long time.  As far as I know, they are working just fine.  One is used every day to export files from a VAX/VMS 5.5-2 data acquisition system to an iMac file server.  That VAX has been running that lab for over 20 years, I think—maybe 30.  We used to run Pathworks/Mac on the VAX until Apple removed support for their own network file protocol and forced us to come up with an alternative.  We run DECnet Phase IV, not Phase V, so we can't do DECnet remote file access over TCP/IP.  I've built other SoC appliances using PlugPCs, such as Ionics Nimbus. My last few projects using SoCs have used BeagleBone Blacks.  Their processors have FPUs, which makes them more useful.  As I recall, Raspberry Pis either did not have an FPU, or priced out more expensive than the BeagleBone Black when I last looked at them.  I set them up to be self-hosting for development.  Cross-development is a royal pain.
> 
> Other discussions here have mentioned using ANSI-labeled tapes.  It is true they can be simple.  But, not if you start dealing with records instead of blocks.  I briefly looked at the ansitpc tool mentioned earlier in this thread at https://github.com/khandy21yo/emutools.  It writes blocks, not records.  It also does not properly write the ANSI labels.  Maybe that is what is upsetting VMS.  I assume VMS figures it out; if not, you definitely want to mount the tape /NOHDR3 on VMS.  The ANSI tape format is an ANSI standard.  I'll grab my copy at work tomorrow and send the number.  I assume the VMS documentation also cites the ANSI standard they implement.

I have two copies of the ANSI X3.27 standard: -1978 (version 3) and -1987 (version 4); -1969 was version 1, which I do not have.  The version number is written as the last (80th) character of the VOL1 (the first) label on the tape.  I'll bet most DEC systems implemented version 3.

> I just stumbled upon a Unix utility that writes ANSI tapes at http://www.math.utah.edu/cgi-bin/man2html.cgi?/usr/local/man/man1/ansitape.1.  It might be easy to modify it to write TPC format volumes instead of starting from scratch.
> 
> Larry Baker
> US Geological Survey
> 650-329-5608
> baker at usgs.gov


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