[HECnet] Effects of Rogue Duplicate HECnet Node?

John Forecast john at forecast.name
Thu Mar 5 09:26:15 PST 2020



> On Mar 5, 2020, at 10:31 AM, Thomas DeBellis <tommytimesharing at gmail.com> wrote:
> 
> I never heard of DECnet on SCO, but we ran Ultrix on the first (8650) and second (8700) VAX's which we got at the data center for instructional use.  My last use of SCO in the early 2000's timeframe struck me as a product that was behind the times.  It still didn't have some features that Ultrix had; Linux and Digital Unix (1990's Alpha) had far passed it by.
> 
In the late ‘80s DEC had the PATHWORKS product for networking with PCs. The first version ran on VMS and a subsequent version ran on Ultrix. Sometime around 88/89 they wanted to build a cheaper, lower end product by porting the Ultrix version to run on a 386/486 running SCO Unix and requested a DECnet implementation. A major problem during the implementation was that Ultrix was BSD based and used sockets while SCO Unix was System V based and used TLI (Transport Layer Interface). We ended up with a user-mode mapping layer but that required intercepting at least fork(), exec() and the initial startup logic so that we could encapsulate the open socket information in environment variables and rebuild the necessary data structures in the forked or new image. Ugly, but it worked OK in this limited environment. After sending  the last message, I found a SPD describing the various PATHWORKS products, including SCO so it probably did ship to some customers.
> As I recall, Ultrix would accept node"user password account"::, the account being necessary because the 20's ran real accounting.  I don't remember the functionality being used much.  Since we got burned with the cancellation of the 2080, we were not inclined to get locked into Digital anything, so no LAT anything.  For terminals, we had an alternate hardware solution (Gandalf PACX) which was more flexible in some ways that could also connect to our IBM mainframes.  For files, the vastly additional functionality of DAP was never leveraged; we stuck with FTP.  We discouraged node"user password account":: as this would allow shoulder surfing.  We may have modified some of the Ultrix source to refuse this nomenclature.
> 
I just tried using this syntax with Ultrix 2.2 and Ultrix 4.0 and neither accepted that format.
> Shortly after we got an 8700, we got our first SPARC and essentially exited any Digital solution afterwards.  DEC tried very hard to keep the account; we got a large number of micro-vaxes, Pro-350's and the like.  I had a micro-vax (running Ultrix) for about 8 months before I left and I thought it quite a reasonable little box.  The Pro-350's weren't really appreciated, this perhaps mostly due to the strange keyboard which didn't have common keys where they have been for decades.  In retrospect, I wonder about that as the keyboard wasn't any stranger than an IBM 3270, which I also used to tweak the HASP (PDP-11) code on the VM side.
> 
> I also used that functionality with our IBM system programmer staff troubleshoot IBMSPL when it got cranky, which happened a lot in early releases.  That surprised me as I had known one of the authors (K. Reti) at Marlboro and he had always struck me as pretty brilliant.  But I was young and impressionable.
> 
> I'm not sure what happened with CCnet after the Columbia data center got out of the Digital.  We had at least one VAX 11/780 on campus (Chemistry), but I don't know what they did.  Digital had better luck with Stevens; for a time, every undergraduate was required to buy a 350 in order to be able to do homework and graduate.
> 
> What's strange is what has lasted.  To this day, you can sign on to IBM mainframe and the only terminal that is supported is a 3270, half duplex.  They all speak IP6 and HTTPS and everything else, but if you are going to write a program under TSO...
> 
> On 3/5/20 8:09 AM, Johnny Billquist wrote:
>> On 2020-03-04 20:59, John Forecast wrote: 
>>> 
>>>> On Mar 3, 2020, at 10:38 PM, Robert Armstrong <bob at jfcl.com> <mailto:bob at jfcl.com> wrote: 
>>>> 
>>>>> The area.node notation, and the Phase 3 numeric address notation, were 
>>>>> intended to be standard, not just limited to NCP.  And indeed DECnet/E 
>>>>> (in RSTS) does both: 
>>>> 
>>>>   FWIW, VMS accepts all three notations too - e.g. ZITI::, 2.16:: and 
>>>> 2064::.  It also accepts the node"name password":: notation as well. 
>>>> Actually I thought this was a standard thing in all "modern" (i.e. Phase IV) 
>>>> implementations.  Are there systems that don't? 
>>>> 
>>>>   And the VMS parser doesn't limit the node name to 6 characters, so you can 
>>>> say "63.1023::" (although HECnet has no such node). 
>>>> 
>>>> Bob 
>>>> 
>>> 
>>> Here’s a few more: 
>>> 
>>> DECnet-RSX 
>>> 
>>>     Kernel interface requires a node name (up to 6 characters) so can only connect to nodes which are in the system database. 
>>>     Access control uses the syntax nodename/user/password/account:: 
>> 
>> I think access control allows either nodename/user/password/account:: or 
>> nodename"user password":: everywhere. 
>> 
>> However, only NCP allows numeric addresses. Anything else needs the nodename. But within NCP you can play using node numbers everywhere just fine. 
>> 
>>   Johnny 
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sonic.net/pipermail/hecnet-list/attachments/20200305/669c5af5/attachment.html>


More information about the Hecnet-list mailing list