I was writing a routine to break out DAP flag bits to aid debugging when
I noticed a possible discrepancy between DAP V5.6 and Tops-20, viz:
DAP
Bit Bit Meaning PDP-10
Bit Tops-20
DAP Symbol
0 Stream Identification Field Present 1B35 HD$SID
1 Length Field Present 1B34 HD$LEN
2 Extended Length Field Present 1B33 HD$LN2
3 Bit Count Field Present 1B32 HD$BCT
4 Reserved 1B31 HD$SEG
5 System Specific Field Present 1B30
6 Not last message of segmented message 1B28
DAP V5.6 reserves bit 4 and defines bit 6 to flag that a segmented
message is being sent and that this is not the last message. In other
words, that there will be another message. Tops-20 is using bit 4 for
this purpose and by rights it would appear that it should be using bit 6.
I will go see if I can't scare up what Tops-10 is doing, but I was
wondering if anyone knew what other OS's are doing.
Tops-20 NFT, FAL and NRT will do something called Poor Man's Routing (or
PMR, for short). The Tops-10 NRT client will also do it. PMR is
something I dimly recall from Phase II or III; this was back before 36
bit hosts could do full routing. Here is some background:
On CCnet, we had enough 20's that not all could be connected to each
other in a star network. Not even Columbia had enough KMC's to 'star'
our 20's; the closest we got was a ring. CMU had even more. When a 20
wasn't next door to whatever system you wanted to get to, you had SET
HOST to one that did and then do another SET HOST accordingly. Or maybe
you had to do that a few times.
The manual procedure and all the accounts involved was clunky enough
that pretty much only systems staff did this. It was out of the
question for researchers and paying customers.
So I /think/ some site on CCnet came up with the idea of automating it
to a certain extent. It was called "Poor Man's Routing" and the way it
worked is that you specified the route to the system in question. Let's
say you were on NODE*A*:: and wanted to go to NODE*C*:: yet did not have
direct connectivity. If both NODE*A*:: and NODE*C*:: had connectivity
to NODE*B*::, then the relevant part of the configuration looked
something like this:
NODE*A*:: ↔NODE*B*:: ↔NODE*C*::
If NODE*B*:: was a PMR host, then you could do something like SET HOST
NODE*B*::NODE*C*:: and the parser would convert this to some
intermediate string. Instead of opening a connection on DECnet object
23, it would use object 123 and NODE*B*:: was responsible for taking the
rest of the string and getting you to the right place.
It worked well enough if the systems in question weren't excessively
loaded (which was invariably /never/ the case) and it saved us when the
dates for version 6 slipped. I had been under the impression that some
site on CCnet had done this and remember eagerly flushing all of it when
we finished the field test.
Much to my surprise an acquaintance of mine at Marlboro (Larry Campbell)
formalized this with a separate module called DNCONN.MAC. I put this
into a conditional assembly in part to save some address space (only to
get blown out of the water by some vestigial code that had never been hit).
Does anybody remember PMR? Did it exist for the other systems which
supported DECnet? Just curious whether I should turn this on for anyone.
PS: So much for my silly subject line of the day...
In TCP, something called the 'push flag' can be set to cause accumulated
data in the monitor (which may be one or more packets) to be sent over
the network. It is often abbreviated as "PSH".
The Tops-20 FTP client and server both set PSH on the last packet of
data from a file to send it on its way. This is done with a SOUTR% JSYS,
which stands for *S*tring *OUT* *R*ecord. This is an overloading of the
hardware record concept which is more commonly associated with
nine-track magnetic tape.
PSH can also be detected on input by doing a SINR%, which stops the
network read early, instead of waiting for a full buffer of data (which
might, in fact, never come).
I believe DECnet transport implements the same semantics, but I would
like to double check that. Where would I go in which part of what
specification? Or does anybody know?
I recently had a number of connectivity issues that caused me to review
my DECnet related batch jobs. The following is a snippet from the log
file of GETNOD, which is the weekly batch job that fetches the latest
HECnet node list from MIM::. I had updated it in part because of
trouble-shooting, but the change isn't dramatic--it's rather more of a
'buff and polish'. The items in red are of note:
20:31:21 MONTR $@NFT
20:31:21 USER NFT>*SET DEFAULTS MIM:: /USER:
20:31:21 USER NFT>*SET DEFAULTS MIM:: /PASSWORD:
20:31:21 USER NFT>*SET DEFAULTS MIM:: /ACCOUNT:
20:31:21 USER NFT>*SET DEFAULTS MIM:: /OSTYPE:RSX11 ;<-- NEW
20:31:21 USER NFT>*DIR MIM::FIX.T20;0
20:31:21 USER
20:31:21 USER [Fork NFT opening DCN:MIM-FAL for reading, writing]
20:31:23 USER %Remote OS type /different/ from that specified with
SET DEFAULT
20:31:23 USER
20:31:23 USER MIM::DU1:[DECNET]
20:31:23 USER FIX.T20;161;P775656 18 35840(8)
18-Oct-2022 09:59:43
There is nothing fatal about the message, but it was surprising.
Investigating the parse table for OSTYPE in NFT.MAC shows:
OSTTBL: XWD OSTSIZ,OSTSIZ ;ARGUMENTS FOR /OSTYPE
T (IAS,.OSIAS) ;Operating system type
; T (OS-8,.OSOS8)
T (RSTS,.OSRST)
T (RSX11,.OSRXM)
T (RT11,.OSRT)
T (TOPS10,.OSTP10)
T (TOPS20,.OSTP20)
T (VMS,.OSVAX)
So the above shows only a single RSX parse item and I had wondered about
that, given all the various flavors of RSX. Further investigation into
DAPSYM.MAC shows what Tops-20 DAP actually knows about (in octal).
.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
.OSTP10==11 ;TOPS-10
.OSOS8==12 ;OS-8
.OSRXP==13 ;RSX11-M PLUS
That's more like it, I would assume. So I guess the fix here is to put
a few more entries into the NFT parse table.
Johnny, which one of the above is MIM:: reporting? I guess 13?
Hi,
Is anybody out there using PyDECnet and GRE over IPv6 who would be willing to set up a circuit between A29RT2 (29.2) and their router?
Regards
Keith
Does anybody have an image of the VAXPAX (the VAX-11 diagnostic pack for
7xx machines, 8xxx, machines, and maybe a few others)?
I have one, but it's a fairly old version. It doesn't have any of the
82xx/83xx diagnostics and EVRLA doesn't know about RA70s.
Thanks,
Bob
Good evening all
Is there a way to connect to hecnet without requiring a nat rule? For
declegacy next weekend I'd rather use the halls WiFi and I don't have
access to their router.
Thanks, Mark
This is a twin/duplex cable of varying length with 100/140 um "multimode"
cores and SMA-906 connectors. SMA-906 connectors have the stepped
center-pin, compared to the SMA-905 which is a simpler straight pin. It's
used, for example, by the LAN Bridge 100.
For additional information see pages 169 through 335 (of 452) in
http://www.bitsavers.org/pdf/dec/comm/EK-CMIV7-RM-005_Communications_Options
_Minireference_Manual_Vol7_Aug88.pdf
Probably it has an orange sheath so it would be somewhat distinctive in your
tangled pile of cables :-}.
Thank you for looking,
paul
