On 6 Jan 2016, at 6:03 PM, <simh-requ...@trailing-edge.com> <simh-requ...@trailing-edge.com> wrote:
> On Jan 6, 2016, at 4:00 PM, <simh-requ...@trailing-edge.com> > <simh-requ...@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@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 > ba...@usgs.gov Larry Baker US Geological Survey 650-329-5608 ba...@usgs.gov _______________________________________________ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
