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
Gents,
It's been a while since I sent out the T1.1 beta 2. I had collected a number of cleanups and bugfixes as well as some doc updates. I don't know how many are using this release; I see one in the mapper but there might be more for all I know.
Earlier today I committed those pending improvements and created a new "T1.1 third beta" kit. You can get that code from the Subversion server:
svn://akdesign.dyndns.org/pydecnet/branches/t1.1/pydecnet
or alternatively from the Downloads link on the mapper website:
http://akdesign.dyndns.org:8080/resources/public/index.html
I'd like to do the V1.1 release reasonably soon, so I'd appreciate any feedback from people who have tried the beta (the earlier version or this one).
paul
Hey folks. This is a bit OT. I've been attempting to build APL-11
for a machine with neither FPP nor FIS, and have hit a wall. I get
multiple "Z" errors from the assembler, which is flagging instructions
whose behaviors differ between PDP-11 models.
Has anyone built this from source for something without FPP/FIS?
This is driving me nuts.
Thanks,
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
