Paul Koning wrote: Excerpt of message (sent 20 August 2009) by Johnny Billquist: ... That said, I have also had problems with the Linux DECnet code. Christine might remember me complaining in the past. :-) It works fine with VMS, but horribly with RSX (which also is true of the LAT code). Although I've not tried doing much with Linux DECnet to RSX it's always seemed to work for me when I have tried it. I suspect that any problems here are much easier to fix. Even though the main protocol is in the kernel (unlike LAT) it's pretty solid code, so anything that needs fixing will most likely be in userspace. Most (though not all!) of that was written from proper specifications so should be easier to work with than LAT. I think it's all userspace programs that I have had problems with. Then again ... I've not had any bug reports from anyone about either and it's quite hard to fix bugs you don't know about :-P Sorry, you're right. I think I've only talked with you on perhaps rather vague terms about the problems I've had. But as we now have HECnet, this is way easier to work on. I suggest you log into MIM, and then just try to do a few different things: 1) Try phone to a Linux box. Initiated from both sides. 2) Try accessing files from both sides to the other side. Neither of these things worked when I last tried. And that's a start atleast. :-) That's not too surprising. Well, yes and no. The lower layers of DECnet are all well documented, and if you implement what the specs say it will work. The application layers are not such a pretty picture. DAP (file access) is reasonably well specified. Unfortunately, there are lots of options or variations. What implementers tended to do is code along the lines of "if I'm talking to VMS then features x, y, z will be there". The right way to do this would be to negotiate feature lists or capability flags, but either DAP doesn't have that or people didn't bother using it. File system differences also play a part, though at least between RSX and VMS that's no excuse, they are basically the same. (RSTS is a different matter, of course -- though it's closer to Unix which helps as far as DECnet/Linux interop goes.) Exactly. RSX and VMS are really similar, so since Linux can talk with VMS systems, it shouldn't be a big thing to talk with RSX as well, but something just isn't working right at all. And RSX can talk just fine with Ultrix, so that shouldn't be a big hurdle either. A bunch of other protocols have no specs, either there simply weren't ever any that anyone could find, or if they existed they weren't published. PHONE and MAIL are examples, as are the remote terminal protocols prior to CTERM. Yeah, I remember reverse-engineering MAIL a year or so ago, when I started hacking away at an unsupported mail client/server for RSX from DEC. The protocol isn't too bad, actually, but do look like it was just grown out of hacks. Phone I have no idea about, and terminal protocols looks like a joke on DECnet. For example, if you want to have a remote terminal session with anything other than VMS (where CTERM is available) you're into OS-specific undocumented protocols. CTERM itself is horrendous. I'm not even sure I want to know exactly how it is expected to work. Line editing is a fine example on how weird and complex CTERM is. If you set host from a VMS system to an RSX system, you will in fact get line editing, since VMS will provide that for you, even though you are actually connected to an RSX system that don't have it. However, line editing will only work within the current line. No history. Now, between VMS systems, line editing works with history. This tells us that editing within a single line is done locally, without sending traffic to the other side. Line recalling, however, is done remotely. But the recalled line must then (appearantly) be sent back to the local machine, so that you can play local line editing on that line. Very sick indeed. No wonder people in general regarded CTERM as a part of VMS, and not a part of DECnet. :-) As for other interactive terminal protocols... I know. DEC actually sent four (or was it five) different applications with RSX for use in connecting with different host types. There is one program for connecting with other RSX systems (apart from CTERM), one for talking with RSTS/E systems, and one for talking with TOPS-20 systems. Hmm, that actually make it four applications. :-) DECnet/Linux has support for some of those because I added them, though I don't think I ever got around to the RSX version. CTERM is one of those modern protocols that is so complex that doing what the spec seems to say is no guarantee of interoperability. But in general the rule for DECnet protocols was "it's the responsibility of the spec to be both correct and complete -- conformance WILL imply interoperability". (Most more recent protocols have abandoned that standard of quality, unfortunately...) The problem was that interoperability was somewhat flaky with CTERM, even though I suspect they did follow the spec. Other protocols appear to have done better. I think DAP would be my choice for the protocol that did it best, although NICE also seems to work pretty well over all variants. Clearly you should feel free to find (or reverse-engineer) the protocol definitions and make improvements to the DECnet/Linux implementation. That's what I did some years ago, which is why DECnet/Linux can actually talk to a DECnet/E system reasonably well. :-) When I have lots of time. There are so many things that I want to do relating to RSX... Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol