Does RSX-11S actually send a different code tham -M ? Or is that a distinction the DAP spec made that isn't valid in the real world? It's not surprising the table would use the -M code since that would be the original common one. I don't know that DECnet on 11D was real, and it seem D wasn't anywhere near as popular as M for a number of good reasons. paul

I’m pretty sure I remember -11S sending it’s own code in DAP. While -11S and -11M (and later -11M+) shared common source code, they each had separate distribution kits. I first met DECnet-11D as a Phase I product running at a customer site in 1976. Later I was project lead for DECnet-11D and DECnet-IAS so it definitely was real. I agree that it wasn’t anywhere near as popular as M. John.

Hmm. Oops. I have to correct myself, as well as Thomas. Looking at the RSX code, the system types are defines as such: ; OSTYPE(1):B Operating system type ; OS$RT 'B'= 1 ; RT-11 OS$RST'B'= 2 ; RSTS OS$11S'B'= 3 ; RSX-11S OS$11M'B'= 4 ; RSX-11M OS$11D'B'= 5 ; RSX-11D OS$IAS'B'= 6 ; IAS OS$VMS'B'= 7 ; VAX/VMS OS$T20'B'= 8. ; TOPS-20 OS$T10'B'= 9. ; TOPS-10 OS$RTS'B'= 10. ; RTS-8 OS$OS8'B'= 11. ; OS-8 OS$MPL'B'= 12. ; RSX-11M-PLUS OS$COP'B'= 13. ; COPOS/11 OS$POS'B'= 14. ; P/OS *** V6.0 *** OS$ELN'B'= 15. ; ELAN *** V7.0 *** OS$CPM'B'= 16. ; CP/M *** V7.1 *** OS$MSD'B'= 17. ; MS-DOS OS$U32'B'= 18. ; Ultrix-32 OS$U16'B'= 19. ; Ultrix-11 OS$MAX'B'= 19. ; Highest legal OS OS$DTF'B'= 20. ; DTF/MVS *** V7.2 (TBS) *** So, RSX-11M-PLUS is 12(10), not 13(8). 13(8) is OS/8. And I have no clue what COPOS/11 is. And I also find is "strange" that OS$MAX is 19, and then you have OS$DFT at 20. I guess if that pops up, it will considered unknown. Half-finished work maybe? And with that said, if FAL in RSX is built, or run on 11S, it will indeed set the OS type to 3. Not sure what you'd do through that FAL though. But it's definitely possible based on the code. Johnny On 2022-10-20 20:10, Johnny Billquist wrote: -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

I believe it is for the menu-driven version of RSX that ran on DEC's PDP-11 based PC.  I believe it was branded "POS" something, but I don't remember what those letters meant.  We had our own local inappropriate meaning of the acronym, which I won't repeat here as, nearly four decades after the fact, I'm really embarrassed by our arrogance.  Anyway, our word has blotted out whatever it meant... What I remember is that the the keyboard drove my manager of the time, Frank da Cruz (or Mr. Kermit) absolutely bonkers as he attempted to test/bring up Kermit on it.  He /really/ didn't like the "Do" button.  Whenever Kermit hung the machine (which was frequently in early versions), he would would windmill his right arm, swooping down and pushing the button, intoning "Do. Do.. Do...  DO!" until he had to reboot/repower.  He got pretty peeved. I forget the product name, but it wasn't Rainbox; that was an 8086 or something. On 10/20/22 5:25 PM, Lee Gleason wrote:

Its main problem was that it had a completely different I/O bus and I/O architecture. And a lot of that went poorly because Intel chips were used for it, and Intel rarely if ever has good design for anything. The interrupt controllers, for example, are a mess. Fortunately, most of its misfeatures are not used on the Pro (like edge-triggered interrupts). The biggest blunder was a set of storage controllers without DMA, even though the bus actually supports DMA according to the documentation. So the hard drives -- not very fast to begin with -- have to be 4:1 interleaved to avoid missing the next sector after an I/O is done. That's true on both F-11 and J-11 based machines, so clearly the CPU speed is not at fault. On the Pro 380, a pile of discrete chips were replaced by one or two gate arrays (so many of those Intel chips disappeared, but not their ugly APIs). Apparently, the designers made the I/O gate array at 10 MHz, and made it synchronous with the CPU clock on the assumption that Harris would deliver its promised 20 MHz J-11. When they did not (18 MHz was the best they could do), the Pro 380 was forced to run the CPU at 10 MHz instead. There was also a Pro RT-11, I don't remember if that was an official product or a midnight project. The RSTS port was definitely a midnight project. And there were two Unix projects. I never remember which is which. One made it to field test -- I had that on my home machine -- but it was canceled before the actual release, Then a different PDP-11 Unix was shipped instead. The field test one had some really weird hacks: I remember a "vi" that didn't update the screen while you were typing, instead you had to hit some special key to force the refresh to happen. My guess is that it was a performance issue, but that seems strange because other software had no trouble doing that sort of thing. paul

I'm really tired of P/OS being characterized as "a hack" or a "bastardized version of M-Plus". Probably 90% of the changes made were the named directory support that was completely rolled back into the M-Plus stream. The rest were changes to be able to run without DCL or MCR. And I believe that ALL changes were reviewed or made by the M-Plus development group. Chuck On Sun, Oct 23, 2022 at 8:03 PM Steve Davidson <steve(a)davidson.net> wrote:

On 2022-10-23 16:56, Paul Koning wrote: True. But even the fact that they decided to make it incompatible with all previous PDP-11s were a bad decision. No matter what chips they used. That they don't use DMA is a mystery to me. Maybe some problems with it? I don't know of a single option that uses DMA. Anyway, I believe an F-11 and a J-11 running at 10 MHz will pretty much perform rather similar. So the 4:1 interleaving, which obviously have to do with CPU speed, is another sign of the problems with the system. As far as I heard/know, the gate array was limited to 10 MHz. Wouldn't have mattered how much faster the J11 could run. In the PRO-380, it would never be run at more than 10 MHz. And I think it sounds weird if the fact that the J11 only reached 18 MHz would be a reason to limit the PRO to 10 MHz. Why not run at 18, or 15, or whatever? The gate array needs to run at the same speed as the CPU, so it couldn't be scaled or anything either. It was also a bit of a midnight thing, but less midnight than RSTS/E. RT-11 did actually ship with the required files to run on the PRO for a number of versions, but it was removed in the last releases, if I remember right. However, if you had an older kit, you could just take those bits (I think mainly drivers) and use them with the latest version of RT-11 and all worked fine. VENIX was the commercially available Unix. So many strange things around the Pro. Good idea; bad implementation. A desktop PDP-11 with graphics... I would have liked that. The Pro - not so much. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

Hi: Talking about P/OS and PRO350... There is a well done emulator: http://xhomer.isani.org/xhomer/ Enjoy ! Paco On Sat, 22 Oct 2022 at 11:55, Johnny Billquist <bqt(a)softjar.se> wrote: -- |_|0|_| |_|_|0| »ö« |0|0|0|

As we've noted earlier, the operating system numbers are not consistent between terminal transport and DAP.  Your numbers correspond to the DAP 5.6 specification as far as it goes, viz:                           Value     OS Type                             0       Illegal                             1       RT-11                             2       RSTS/E                             3       RSX-11S                             4       RSX-11M                             5       RSX-11D                             6       IAS                             7       VAX/VMS                             8       TOPS-20                             9       TOPS-10                            10       RTS-8                            11       OS-8                            12       RSX-11M+                            13       COPOS/11 (TOPS-20 front-end) I wish I hadn't sent out my last email because P/OS was staring me right in the face...  I don't recall there being any COPOS/11 on any Tops-20 front end.  The master DTE ran RSX20F, the RJE ran DN60 code and the Phase III DN20's ran what I thought was called "MCB". The Tops-20 DAP library has the following operating system numbers which partly correspond to yours.  By this, I mean they are table offsets which are used to pick the default mode. Assuming the following:         .OSRT==1        ;RT-11         .OSRST==2       ;RSTS/E         .OSRXS==3       ;RSX-11S         .OSRXM==4       ;RSX-11M         .OSRXD==5       ;RSX-11D         .OSIAS==6       ;IAS         .OSVAX==7       ;VAX/VMS         .OSTP20==10     ;TOPS-20 (^D8)         .OSTP10==11     ;TOPS-10 (^D9)         .OSOS8==12      ;OS-8 (^D10)         .OSRXP==13      ;RSX11-M PLUS (^D11) It would appear that there is a conflict in the list in the PDP-8 entries and RSX-11M+.  If MIM:: is reporting decimal 11 (octal 13), the right thing from my list, then it is reporting itself as a PDP-8 running OS-8 according DAP 5.6. So... go with what MIM:: says, not what is documented? ------------------------------------------------------------------------ On 10/20/22 4:38 PM, Johnny Billquist wrote:

It's taken me over a month to put some data together, both tabulating from various sources and observing what is actually going over the wire. The basic problem was that some changes that I had previously made to DAP, NFT, FAL and friends to write protect the code space /silently/ left things in such a fragile state that trying to link the relocatable binaries (I.E., .REL files) into  an NFT execute either outright blew LINK up or hung it in an endless loop.  That's right: Boom...  I don't think I've ever seen that. Fixing LINK didn't seem to be obvious and I didn't want to get into pile of code as I judged this to be a one to two year rabbit hole because it would turn into a rewrite to use extended mode and support long symbols. Briefly, the problem turned out to be that if you are using Read-Only .PSECT's (a relatively late MACRO feature) in a GLXLIB program, you /must/ name your code segment .HIGH. and your data area DATA.  I got the data part correct, but committed the unforgivable sin of naming the code segment "CODE"...  Go figure. So MIM:: is sending an OS Type of 12, just like it's supposed to, and Tops-20 doesn't recognize this.  The recovery works well enough, it seems, Tops-20 DAP merely whining, but carrying on.  So I'll fix that.  It seems the best way to go is to simply mimic the RSX naming paradigm; that is, RSX OS$XXX would go to .OSXXX. I'm wondering whether I should double check the FILESYS byte.  Probably. RSX Symbol RSX Value RSX OS Type DAP V5.6 Value DAP V5.6 OS Type Tops-20 DAP Symbol Tops-20 DAP Value Tops-20 DAP OS Type OS$RT 1 RT-11 1 RT-11 .OSRT 1 RT-11 OS$RST 2 RSTS 2 RSTS/E .OSRST 2 RSTS/E OS$11S 3 RSX-11S 3 RSX-11S .OSRXS 3 RSX-11S OS$11M 4 RSX-11M 4 RSX-11M .OSRXM 4 RSX-11M OS$11D 5 RSX-11D 5 RSX-11D .OSRXD 5 RSX-11D OS$IAS 6 IAS 6 IAS .OSIAS 6 IAS OS$VMS 7 VAX/VMS 7 VAX/VMS .OSVAX 7 VAX/VMS OS$T20 8 TOPS-20 8 TOPS-20 .OSTP20 8 TOPS-20 OS$T10 9 TOPS-10 9 TOPS-10 .OSTP10 9 TOPS-10 OS$RTS 10 RTS-8 10 RTS-8 .OSOS8 *10* *OS-8* OS$OS8 11 OS-8 11 OS-8 .OSRXP *11* *RSX11-M+* OS$MPL 12 RSX-11M+ 12 RSX-11M+ OS$COP 13 COPOS/11 13 COPOS/11 OS$POS 14 P/OS OS$ELN 15 ELAN OS$CPM 16 CP/M OS$MSD 17 MS-DOS OS$U32 18 Ultrix-32 OS$U16 19 Ultrix-11 --T ------------------------------------------------------------------------ On 10/22/22 6:03 AM, Johnny Billquist wrote:

On 2022-11-21 15:25, Paul Koning wrote: Totally agree. And I think/hope RSX does this. But if anyone spots RSX acting strange, let me know. VMS, unfortunately, broke things in many ways as they more and more assumed that there was just VMS anywhere anyway. The MAIL11 server certainly have some very broken bits as well, that I noticed. And CTERM usually is a bit odd with anything non-VMS. :-) As far as I understood, Thomas was thinking of/referring to the naming of symbols in the source code. In RSX you have OS$xxx, and Thomas was thinking of just taking the TOPS-20 format, which is .OSxxx and just copy the xxx part from the RSX symbols over to the TOPS-20 symbols. But things you say about filename string parsing is certainly true as well. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

Interesting; I was wondering why you picked a special number?  I would imagine that most implementation wouldn't know it and maybe Ultrix-32 (OS$U32==^D18) might have been a better choice?  Ultrix-32 is of interest as its NRT is compatible with Tops-10/Tops-20 and has the same OS type number. I ought to update my spreadsheet to see how the Tops-20 NRT numbers now align with the fixed DAP numbers. Is there an implementation of your DAL on HECnet?  I'd be happy to see if Tops-20 FAL/NFT/DAP chokes on it.  Considering Paul's previous points about OS type, one assumes it should not be failing (if it does). The Tops-10 and Tops-20 NFT/FAL/DAP implementations do not appear to share the same code base.  That's of interest because a number of the DECnet transport monitor modules do.  Phase II NICE doesn't.  Later NICE is written in BLISS, which is suggestive, but it was never released to my knowledge. I'm not sure if it's 'unfortunate'.  They /might/ have because Tops-20 NFT/FAL/NFT are GLXLIB based and could /maybe/ be enhanced to run on both operating systems.  'Enhanced' does not necessarily imply a trivial amount of work as the OS calls and job structures are quite different as are the file systems.  GLXLIB does a good job against shielding you against the latter. The job structure (I.E., how you run FAL) is vastly different.

On 2022-11-21 19:26, Paul Koning wrote: Yeah. NRT is a bit odd. And unless I remember wrong, some variant don't even send anything at the start, so it's even more screwball to identify what you should try and speak. Right. Once you have some data, there is better information than the OS identifier. I'm not sure I agree. While I don't mind grabbing some undefined/reserved number for a new implementation, Linux is after all just another Unix in this sense, and would suite very well into just pretending to be Ultrix. Shared codebase seems rather irrelevant. It's much more about the actual properties and behavior of the system. I generally always group all Unix-like systems together. There are some times when you want to differentiate between them, but for network protocols like this, I can't think of a single reason. In a sense, they have a very shared ancestry. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

On 2022-11-21 20:53, Paul Koning wrote: You forget fast. :-) Here is what I wrote in August this year: ==========snip========= Paul. Back home and able to check things. This is rather interesting, and way more complicated, it would appear, from reading the RSX sources. Starting with the client that connects to VMS: CMPB #1,CNFBUF ; IS IT A CONFIGURATION MESSAGE BEQ 100$ ; IF EQ, YES 90$: CALLR ERR17 ; ISSUE ERROR MESSAGE 100$: BIT #4,CNFBUF+6 ; DOES REMOTE SPEAK VMS PROTOCOL BEQ 90$ ; IF EQ, NO So this seems to align properly with what you described. Now, looking at the client that connects to RSTS/E: First some definitions: ; ; REMOTE DEVICE PROTOCOL DEFINITIONS ; ; DEFINED FOR RSTS NETWORK TERMINAL PACKAGE, "NET" AND "NPKDVR" ; .ASECT .=0 R.TYP:: .BLKB 1 ; MESSAGE TYPE RT.CFG==1 ; CONFIGURATION MSG RT.CTL==2 ; CONTROL MSG RT.UNS==3 ; UNSUPPORTED MSG RT.CON==4 ; CONTINUE MSG RT.DAT==5 ; DATA MESSAGE R.LEN:: .BLKB 2 ; MESSAGE LENGTH RM.HLEN==.-R.TYP ; LENGTH OF MESSAGE HEADER R.RES:: .BLKB 133. ; REST OF MESSAGE (SEE BELOW) RM.MAXLEN==.-R.TYP ; MAXIMUM MESSAGE LENGTH ; (ACTUALLY RSTS SENDS LONGER MSGS -- ; UP TO THE NSP MAX MSG LENGTH. ; BUT THIS IS THE MAX WE EVER SEND.) ; ; CONFIGURATION MESSAGE ; . = R.RES ;POINT TO REST OF MESSAGE (ABOVE) R.OST:: .BLKB 1 ; OPERATING SYSTEM TYPE RO.RT==1 ; RT-11 RO.RST==2 ; RSTS/E RO.RXS==3 ; RSX-11S RO.RXM==4 ; RSX-11M RO.RXD==5 ; RSX-11D RO.IAS==6 ; IAS RO.VMS==7 ; VMS R.VER:: .BLKB 5 ; VERSION NUMBERS R.MOD:: .BLKB 1 ; SESSION MODE R.MNU:: .BLKB 1 ; MENU FOR REST OF CONFIG MSG ; (NO MORE DEFINED NOW) And then the code: CMPB #RT.CFG,CNFBUF+R.TYP ;* IS IT A CONFIGURATION MESSAGE BEQ 40$ ; IF EQ, YES 20$: CALL ERR17 ; ISSUE ERROR MESSAGE BR 70$ ; PROCEED 40$: CMPB #RO.RST,CNFBUF+R.OST ;* DOES REMOTE SPEAK RSTS PROTOCOL BEQ 45$ ;* IF EQ, YES CMPB #RO.RST,CNFBUF+4 ;* RSTS PROTOCOL WITH STANDARD CFG? BNE 20$ ;* NO, REJECT THIS HOST 45$: So here, the code checks the OS type, and in fact seem to claim that +6 is in the version value area. No bitmask for different protocol styles. I'm also wondering why it checks CNFBUF+R.OST, and if that fails, it checks CNFBUF+4, which is the same thing. Looking at the TOPS-20 client, there don't seem to be any system checking or init message at all. And indeed, if testing, I can connect to MIM using the TOPS-20 client. However, as soon as I type anything, I get disconnected. Probably because the RSX server expects an INIT message, and none is coming. Finally, RSX client to RSX seems to match the VMS pattern, with both OS type and a bitmask in the next word telling protocol type. Based on this, I would say that conflating the different clients into one seems almost impossible. ==============snip============= So basically, the TOPS-20 NRT server is not sending anything when you connect, and the RSX NRT client for connecting to TOPS-20 is also not expecting anything. And the other clients I have do things in different ways. Well. Depends on how you look at it. You could just as well argue that this supports my point. With RSX, it is shared source, but the actual behavior in the systems actually differ. -11M only have UIC based directory names, octal version numbers, and just simple device names. -11M-PLUS have UIC and also named directory names, decimal version numbers, and full logical names. Very close to how VMS looks and feels, basically, except no subdirectories. (And I won't even talk about -11S) So common source is not really a good way to group things by. Makes more sense to talk about the behavior and properties. But I would agree that -11M, -11D and IAS could probably very well have shared the same id. Agreed. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

On 2022-11-22 06:02, Thomas DeBellis wrote: [...] [...] Trying to remember here, since it's now a few months since I looked at it. I think that I later concluded that the server might sent an init, but the client is not expecting/requiring it. Which would suggest that it might not be sent by all versions, so it's not reliable. I don't think it sends any INIT either. It just starts running, assuming it works on a stream of bytes with no further interpretation. But this is mostly me trying to recollect what I found out in August. I do not know why specifically the TOPS NRT client under RSX works this way, but I would assume there is a reason. The RSTS/E, VMS and RSX clients do expect an INIT packet, and the majority of the code is shared by all the clients under RSX. If you really want to, I can go digging in the code again, or we can try and find all the mails that were sent in the late summer. :-) Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

That fits what I know, and documented in the protocol doc in the PyDECnet source tree. Config is a required message from server to client. The RSTS and RSX protocol variants then do a response config message from client to server, but the TOPS-20 variant does not. paul

I think that's a DAP protocol version issue; it shouldn't be tied to OS type. There are some incompatibilities like that between DAP 5.6 and DAP 7.0. The VMS microfiche that were posted a while ago give some clues; just enough that I could beat my Python implementation of NFT into behaving. You could use that for reference. paul

Here you go: http://www.bitsavers.org/pdf/dec/vax/microfiche/vms-source-listings/AH-BT13… The .bw scans are much smaller than the .gray scans; the conversion to bitonal seems to be quite good so the .bw ones are the ones to use. paul

On the V7 differences, here's one example (taken from the FAL implementation in PyDECnet). There are a couple more in the code.. def dodir (conn, req): for fn, resp in files (conn.v7, req): for r in resp: conn.send (r) if conn.v7: # V7 has an Ack after each entry. VMS cares (RSX does not). conn.send (Ack ()) msg = AccComplete (cmpfunc = AccComplete.RESPONSE) conn.send (msg) conn.flush () paul

Johnny and I did a lot of work and testing to get Tops-20 DAP/FAL to perform better.  Some were Tops-20, others not.  One Tops-20 bug was that an eight bit file would cause a directory listing to stop.  My favorite RSX issue was that it wants UPPERcase month names; I fixed that by UPPERcasing the result of ODTIM%. I can't remember what Johnny did (if anything). Well, when if one is ever available on HECnet, I'll be /delighted/ to test against it. Meanwhile, now that I am finally able to assemble and LINK a working NFT and FAL and have fixed the incorrect OS type number issue, I bumped into another problem.  Naturally, it's doing directories.  When doing an ANONYMOUS directory of MIM:: (I.E., DIR MIM::*.*), I got: MIM::DU1:[DECNET] .... [Parsing Name message] [Parsing Attributes message] [Parsing Date/time Attributes message] [Parsing File Protection Attributes message] [Parsing Name message] DTRCOM.LST;115;P775656          10 18944(8)   24-Oct-2021 15:06:46 [Parsing Name message] [Allocated Receive buffer (Words=225 Len=1056)] ?Logical link reception error - Record is longer than user requested Logical link abort reason(0) - No error So it died on whatever the file is that follows MIM::DU1:[DECNET]DTRCOM.LST;115 Sigh...

Oh.  Don't be surprised. When I write protected what would be GLXLIB's high segment on Tops-20, the only way to do this is with .PSECT's, but GLXLIB makes a lot of assumptions about addresses.  On Tops-10, the GLXLIB high segment is write protected, and I think that is the right thing to do for all executable code.  I also moved GLXLIB as high as i could in the address space to allow GLXMEM on DAP's behalf to snarf really huge chunks of memory, which get filled up on large directory responses.  This is the default GLXLIB memory address space lay out:   Section 0    R, W, E,  Private 0           TOMMYT:<SUBSYS>GLXLIB.EXE.5  1   R, CW, E 400-432     TOMMYT:<SUBSYS>GLXLIB.EXE.5  2-34 R, CW, E Tops-10 fans will note that page 400 is the historic address of the high segment and this dates back to KA days.  I think that was just a convention and that it could be different, but I don't remember.  Bob?  This is the new layout:   Section 0    R, W, E,  Private 0 STAR:<GALAXY-SOURCES.GLXLIB>GLXLIB.EXE.92  1   R, CW, E 637-673  STAR:<GALAXY-SOURCES.GLXLIB>GLXLIB.EXE.92  2-36 R, E Note that GLXLIB is much higher--in fact, it is as high as it can go before bumping into DDT (if DDT is in the same section).  It is also write-protected. Another reason I did this was to see what kind of bugs it would shake out and I've gotten a few, which is the reason for the two pages of added code (28 pages to 30, a big whopping 15K ...)  I also lifted some nifty stuff from Tops-10 GLXLIB; the sources diverged. ------------------------------------------------------------------------ On 11/22/22 4:54 AM, Johnny Billquist wrote:

The DAP spec describes the month part of the date, and it shows specifically upper case strings. So while one might argue RSX is too picky, sending mixed case month names is not allowed by the protocol spec. paul

For RSTS/E at least, that's often true in the later versions, not so much in the early ones. And it requires work to do case-insensitive matching, which was made easier in a later RSTS/E version (V5 or V6 I think) with a string transformation function in Basic-Plus. Before then, e.g., in RSTS V4, being case insensitive was a major hassle and unlikely to be practiced consistently. As for protocols, that's different from user interfaces. If there is a list of values you should assume that's the list, and not rely on fuzzy matching unless explicitly mentioned in the document. Unlike RFCs, DECnet specs should be treated as exact and complete, because by and large they are. paul

On 11/22/22 00:18, Thomas DeBellis wrote: I'm sorry, I missed this. What are you looking for on HECnet? -Dave -- Dave McGuire, AK4HZ New Kensington, PA

Have you tried this on other distros, like Debian, Ubuntu or Mint? Bob

Can you still get DECnet for Ubuntu?  I had thought that it was dropped from the Linux kernal. On 11/22/22 11:49 AM, Robert Armstrong wrote:

Yeah, that's been coming for a while. DECnet support is already a separate, loadable kernel module, but things in the kernel change all the time (and sometimes gratuitously, I think). Without somebody keeping the DECnet module up to date, it would quit working in short order. Nobody wanted the job. ZITI runs Ubuntu 16.04 LTS with ESM and it's a fairly old kernel - 4.4 something. Looking thru my notes it seems like I tried to run John's Raspbian build on it before, in the summer of 2020, and ran into a few problems. I'll pull the latest version over the holiday and try it again. Bob

No, unfortunately not. Due to family medical issues I don’t get much time to spend on such things. John.

So your employer doesn't do any open source work? Hm. Then again, "they own it" isn't actually a bar. It just means any Linux contribution you write would have they company name on it as the copyright holder. The actual issue isn't ownership but whether the company is willing to publish any work under the GPL. I have in the past contributed GPL work assigned to the FSF (GCC, GDB) and I have also been involved in stuff that goes into Linux. The latter will appear (when it's released, which hasn't happened yet) as GPL stuff (of course, being Linux bits) copyright Dell. Linux is fine with that. paul

Dave, Unfortunately I had no choice. The only exception is for software that I own or have been working on since before joining them. What I have in writing is in the hands of my lawyer (my son) just in case. My son was VERY clear with them what was acceptable and what was not. So it goes… I do not write software for them. I had absolutely no interest in doing that after these discussions/negotiations! -Steve SF:IP2

Wow, that may be one the most fascist policies I have ever heard of.  I know people who work for defense contractors and not even they have these kinds of legal shackles.  You have my sympathies. My employer (Big Bank) is emphatic about what I write for /them/, which is understandable.  There are no clauses for what I write on my own time unless I derive revenue from it, in which case I have to inform them, but they still don't own it. They actually did run Tops-20 back in the 80's, but all of that has been scattered to the Four Winds of Heaven.  I don't think I know anybody there any more who would even recognize the name. I would be beyond delighted to be paid for any of my fixes, but at this point of my life, I'm happy to be paid for /anything/ instead of being similarly kicked to the curb for having committed the unforgivable sin of growing older...

Looks like the earliest kernel I tested was 4.19.93 John.

I assume you mean Mac OS running DECnet (in the OS) the way Linux can, right? I haven't heard of any such thing and wouldn't expect one to exist. You can of course implement it an in application, like PyDECnet or the C Router. paul

Hello Paul, Thanks for the detailed and, as always, very informative response! In retrospect, perhaps some of my wording is unfortunate and/or insufficient.  Let me try to clarify/elaborate: Yes, you've said it and I think maybe more than once.  This is an important point and I don't disagree.  Hardly.  You may recall that, based on your observation, I changed Kermit-20 (and SETHOST, I think) to check the NRT protocol type instead of the OS Type.  There, I only use the OS Type to print nice informative messages. For what it's worth, neither Tops-20 NFT nor FAL have any VMS specific code.  NFT will parse an OS Type keyword, yet it does nothing but hand the OS Type code to DAP.  Historically, DAP largely used that information to handle how the VAX was acting incorrectly with the apparent tacit understanding that the behavior would be remediated.  Edit 106 is instructive: The maximum value of DPMXM was lowered to ^d1636 if the user said /OSTYPE:VMS in SET DEFAULT.  This is the largest it can be and still allow VAX FALs to function if the VAX users accounting file allows BYTLM to default to 4K. If BYTLM is too small for DPMXM, then the VAX FAL hangs.  If all VAX users have BYTLM raised, then DPMXM can also be raised. Doing this provides better performance.  Note that the next release of VMS FAL should include a patch to solve this problem.  When NFT/FAL-20 is shipped with DECnet-20 Phase III this patch should be removed. This was, in fact, eventually removed as part of Edit 161, viz: Remove edit 106 to DAPLIB which compensated for BYTLM being too small on a VAX/VMS account prior to DECnet-VMS V.3.1 and VMS V3.4.  This eliminates "data overrun" errors seen when transferring files from a -20 to VAX running VMS V3.4 or greater. Among other things, OS Type byte is still used to pick the default file mode, viz: .MD1==^D1      ;/IMAGE .MD2==^D2      ;/IMAGE/FIXED .MD3==^D3      ;/IMAGE/VARIABLE .MD4==^D4      ;/IMAGE/MACY .MD5==^D5      ;/MACY .MD6==^D6      ;/MACY/FIXED .MD7==^D7      ;/MACY/VARIABLE .MD8==^D8      ;/ASCII .MD9==^D9      ;/ASCII/FIXED .MD10==^D10    ;/ASCII/VARIABLE .MD11==^D11    ;Print file format .MD12==^D12    ;Fortran format Tops-20 DAP has a lot of special cases to handle the PDP-10's variable byte sizes.  There is no more any special casing for VMS as far as I can tell.  The only other OS type specific special casing that I see is for RSTS/E, but I have not reviewed that in depth, yet. Yes, but I didn't mean base decisions on the FILESYS byte.  What I meant was, "I wonder where else Tops-20's DAP has different numbers than what is specified in DAP V5.6?  I ought to at least double-check whether the FILESYS byte definitions jive."  I have and they do. That's an excellent point, and this is, in fact, done.  However, it is not what I meant.  I simply meant what sort of naming convention should I follow when coining new symbol names and that it seemed to me that it might be useful to either follow or at least mimic or 'rhyme' with what Johnny sent me for RSX.  In other words, RSX Symbol RSX Value RSX OS Type Tops-20 DAP Symbol OS$RT 1 RT-11 .OSRT OS$RST 2 RSTS .OSRST OS$11S 3 RSX-11S .OSRXS OS$11M 4 RSX-11M .OSRXM OS$11D 5 RSX-11D .OSRXD OS$IAS 6 IAS .OSIAS OS$VMS 7 VAX/VMS .OSVAX OS$T20 8 TOPS-20 .OSTP20 OS$T10 9 TOPS-10 .OSTP10 OS$RTS 10 RTS-8 .OSRTS OS$OS8 11 OS-8 .OSOS8 OS$MPL 12 RSX-11M+ .OSRXP OS$COP 13 COPOS/11 .OSCOP OS$POS 14 P/OS .OSPOS OS$ELN 15 ELAN .OSELN OS$CPM 16 CP/M .OSCPM OS$MSD 17 MS-DOS .OSMSD OS$U32 18 Ultrix-32 .OSU32 OS$U16 19 Ultrix-11 .OSU16 Here, the red means the corrected Tops-20 DAP symbol definitions and the green are the new definitions.  You will note that the last three letters for these new symbols are the same as RSX and I thought there might be some value in that as a reminder when trouble-shooting. Maybe naming convention is the better term than paradigm?

On 2022-11-21 16:32, Robert Armstrong wrote: I don't think anyone actually knows. But someone found some mention of it being some kind of FE for TOPS, but it't not *the* FE, as far as I could understand. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

ELAN is a VAX real time kernel, designed to allow the creation of memory-only applications. An example of a product built on top of ELAN is the LPS40 PostScript printer, paul