L.S.
Currently I am finishing testing for the release of the last member of the Pdp8 series computers: Simh Pdp8a with some new devices (and some from old not present in Ppd8).
Current state of affairs is, that it is running Os8 V3S 128k monitor and the Kt8 diagnostics and is stable.
Also F4 runs and basic Rts8 V2b and V3.
The last hurdle is to activate Decnet8 as the last test station to really load a Pdp8 with some realistic real time work.
However ?.
Activating Decnet8 leads to a lot of funny but nasty surprises and is tedious at best.
Basic software can be found on the internet with only 2 flavors of Nip and Nsp which differ only slightly.
The setup, assembling and loading is easy enough, though Nip02 uses a thing that is only available in Rts8 V3 exec although it was released for V2b.
That should be catched with prerelease testing.
The initial point is already, that the Ddcmp lines are not starting up automatically.
Looking in the code there are pointers to things with temp status or not implemented, like the STRTUP function code in Nsp which might be needed to startup the lines.
There are quite some discrepancies between current available Decnet8 and the documentation in Decnet8.pdf as can be seen with the Nip report:
According to the Decnet8 doc copyrighted in 1977, the example display of status looks as follows:
4.5 SAMPLE NIP PRINTOUT
The following is a typical NIP printout:
NETWORK INFORMATION PROGRAM V1
PHYSICAL LINE STATUS [DDCMP V4B]
LINE NODNAM (#) STATE DRIVER VRSN UP SINCE
0 ACTON (3) ON-LINE KL8J 3A 8:03:35 28-DEC-76
1 MAYNRD (2) OFF-LINE DKC8 2B
2 CONCRD (5) STARTING LOCAL 15A
LOGICAL LINK STATUS [NSP VllE]
CHAN STATE LINE TASK SRCE-NAME[PPN] TYPE LINK DEST-NAME[PPN] TYPE LINK
1 IN-USE 0 12 TARZAN[6,0] 10 4 JANE [3,1] 7 6
2 WAKING 1 3 DONALD[2,2] 3 3
3 UNUSED 1 3 DUMMY [4,4] 29 14
4 BOOT 2 6 MASS [1,23] 3 44
PHYSICAL LINE ERROR STATUS
LINE 0:
3 NAKS WITH HEADER CRC ERRORS
5 NAKS WITH DATA CRC ERRORS
83 NAKS WITH REP ERRORS
1 NAK WITH BUFFER UNAVAILABLE
2 NAKS WITH HEADER FORMAT ERRORS
192 NAKS WITH MESSAGES TOO LONG
100 MSGS WITH HEADER CRC ERRORS
1 MSG WITH REP ERROR
1 MSG WITH DATA OVERRUN
10 MSGS WITH HEADER FORMAT ERRORS
9 MSGS WITH MESSAGES TOO LONG
LINE 1: NO ERRORS
LINE 2:
3 NAKS WITH DATA OVERRUNS
1 MSG WITH REP ERROR
A real printout on the current generated system is as follows:
NETWORK INFORMATION PROGRAM V1C
PHYSICAL LINE STATUS [DDCMP V1A]
LINE NODNAM (#) STATE DRIVER VRSN UP SINCE
0 UNKNOWN***** OFF-LINE KL8J 1A
LOGICAL LINK STATUS [NSP V1C]
CHAN STATE LINE TASK SRCE-NAME[PPN] TYPE LINK DEST-NAME[PPN] TYPE LINK
1 UNUSED 0 36 TLK [1,2] 0 0
PHYSICAL LINE ERROR STATUS
LINE 0: NO ERRORS
0 MESSAGES TRANSMITTED
0 MESSAGES RECEIVED
The following oddities ? amongst more - can be seen:
1. The date is 28-dec-76, the various edit dates in the current software are all centered on april/may-77.
2. Ddcmp is dated 7-apr-77 with version 1A, the doc mentiones already 4B
3. KL8 ISR is versioned 3A while the current available version is 1A and dated at 8-apr-77
4. And then the Nip version V1 as documented is older than the V1C version of the internet release!!
And there are a lot more things going on. So the bottom question remains: has anyone seen the internet versions working or is there a clobber up between an advanced laboratory (Phase-II??) version as documented (look at the Ddcmp versions) and a preleased or prior old Decnet version. And if so, can anything be retrieved or is it lost forever.
Best regards,
RV
Hi folks,
I have become the proud owner of a VAXmate workstation, with a disk
enclosure pizzabox attached.
It is working in that it attempts to boot from disk (which fails), and
then boots from the network, and I see a load request coming in on my VAX.
Now I am looking for the supporting software.
It looks like Pathworks V4.1 could be of use. I have tracked a kit
PCSACLIENT041 (.A and .B), but it requires the PCSA041 server kit, of
which, oddly enough, I do have .B but not .A
Is the PCSA041 kit available on HECnet somewhere ?
*Wilm*
Folks,
I tried to email to SIMH mailing list but I got delivery failure message.
I have some network access problems when it messed configuration up
overnight because I can't access any with hostnames but only IP addresses.
That cause conflict with network manager service.
I successfully set up br0 as permanent setting by using nmcli commands.
$ nmcli con add type bridge ifname br0
$ nmcli con add type bridge-slave ifname ens33 master br0
$ nmcli con up br0
I tried to set up tap devices but I kept getting connection failure. SIMH
simulator can't access tap devices - no operation permit errors.
$ nmcli con add type tun ifname tap0 con-name tap0 mode tap owner `id -u`
$ nmcli con add type bridge-slave ifname tap0 con-name tap0 master br0
$ nmcli con up tap0
Does anyone know any successful setup by using nmcli for creating tap
devices as permanent configuration?
I removed some br0 setup from tap-setup.sh and successfully set up tap
devices by using ip commands.
My modified tap-setup.sh script here:
# Using nmcli for creating br0 device first at once
#
# $ nmcli con add type bridge ifname br0
# $ nmcli con add type bridge-slave ifname ens33 master br0
# $ nmcli con up br0
# Create the TAP network devices
/sbin/ip tuntap add dev tap0 mode tap
/sbin/ip link set dev tap0 up
/sbin/ip tuntap add dev tap1 mode tap
/sbin/ip link set dev tap1 up
/sbin/ip tuntap add dev tap2 mode tap
/sbin/ip link set dev tap2 up
/sbin/ip tuntap add dev tap3 mode tap
/sbin/ip link set dev tap3 up
# bridge in the tap devices
/sbin/brctl addif br0 tap0
/sbin/ip addr flush dev tap0
/sbin/brctl addif br0 tap1
/sbin/ip addr flush dev tap1
/sbin/brctl addif br0 tap2
/sbin/ip addr flush dev tap2
/sbin/brctl addif br0 tap3
/sbin/ip addr flush dev tap3
/sbin/brctl show
Hi Paul,
I have tried your router but it gave some problems on Centos 6.10 to get it
running, though at first it ran well but had some routing problems I told
you about.
I had to do some things to get it up, but later in the process of updating
pydecnet, Centos started at a certain point complaining about corrupted
kernel.
I do not speak Unix very well, so I may well have installed to many basic
things to get it running and therewith contaminated something.
Point is that with simh logging, I already can see enough about packets
interchange, however there is no exchange at all at the moment: it is stone
dead.
Activating Tlk to force some internal activity leads directly to a halt
instruction with not a very illuminating comment as explanation.
Injecting a packet from a Vax async ddcmp line leads to reception and
discarding of the sync preamble and then a halt instruction for packet
fragmentation.
Of course I was playing false with it, as the start message had C0 for flags
that Decnet8 expects to be a fill, whatever the fill value may have been
expected.
There I can make use of your product to excite the system somewhat.
By the way, the current Decnet8 is imho NOT phase II; I suspect they had it
running in the laboratory (viz Ddcmp version 4B versus V1C) and in the spd
claiming compatibility with Pdp11 phase-II products, but it probably never
got outside the gates.
The mixed dates are a mystery but some Dec people should be around with
knowledge about this.
Moreover, I suppose the main driving force for the Pdp8A with notably the
Kt8 was from LSG as the Psdp8a was also an Anf10 workstation (680) though
with limited caps.
Thanks,
Reindert
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf
Of Paul Koning
Sent: Monday, 19 October, 2020 23:27
To: hecnet at update.uu.se
Subject: Re: [HECnet] Decnet8: Who has any knowledge about this product and
has seen it actually working in whatever versions?
> On Oct 19, 2020, at 5:01 PM, R. Voorhorst <R.Voorhorst at swabhawat.com>
wrote:
>
> L.S.
>
> Currently I am finishing testing for the release of the last member of the
Pdp8 series computers: Simh Pdp8a with some new devices (and some from old
not present in Ppd8).
>
> Current state of affairs is, that it is running Os8 V3S 128k monitor and
the Kt8 diagnostics and is stable.
> Also F4 runs and basic Rts8 V2b and V3.
> The last hurdle is to activate Decnet8 as the last test station to really
load a Pdp8 with some realistic real time work.
Nice!
> ...
> And there are a lot more things going on. So the bottom question remains:
has anyone seen the internet versions working or is there a clobber up
between an advanced laboratory (Phase-II??) version as documented (look at
the Ddcmp versions) and a preleased or prior old Decnet version. And if so,
can anything be retrieved or is it lost forever.
I can't help with your detailed questions. But in case it wasn't well
known: yes, I believe DECnet/8 is Phase II. That means you need either a
Phase II, or Phase III DECnet product to talk to it, or you need PyDECnet.
That's Phase IV but unlike the normal case, it supports all the way back to
Phase II.
It also has detailed packet tracing, so you might find it a useful peer to
use for debugging your DECnet/8 system. For example, if DDCMP is giving you
trouble you should be able to see what you're receiving from the DECnet/8
system.
paul
Folks,
I was going to install RaspberryDECnet on my Linux VM (running on PC) but is
only designed for Raspberry Pi cards. Will they work on x86/x64 linux
distros or Ubuntu 20.04?
I am waiting for new Pi Case 40 package that I backed on Kickstarter and
submitted survey on backerkit soon. I am also getting 2 Pi 4 8GB cards. New
Pi Case 40 now provide new SSD slot for larger SSD drives.
I did not see any lat login programs on that because it is not part of
DECnet kit. Are you still working on LAT login programs and latd daemon
server? I have old DECnet for Linux package that includes lat login
programs. There is a copy of LAT specification on bitsavers.
Thanks,
Tim
Hi Mark (Darvill) - by any chance, would you have any pointers to DECnet
for RT-11?
Regards
Supratim
--
Supratim Sanyal, W1XMT
39.19151 N, 77.23432 W
QCOCAL::SANYAL via HECnet
I was updating some of MRC's late changes into my version of PANDA.? A
(very) few of these were not documented with a change number, so I had
been caught by surprise.? While doing this, I stumbled over some
defensive coding that he had put in to keep even an enabled WHEEL or
OPERATOR from doing something /Really/ /Bad/.
I got to wondering about this, which led me to think about the use of
the OPERATOR id, which is analogous to the [1,2] PPN under Tops-10 and
maybe having administrator rights under Windows, not as bad as root.
Tops-20, like most mainframe operating systems of the day, assumed a
trained operations staff (as in trained to "DON'T TOUCH") and a trained
systems programming staff.? However, this all-or-nothing approach
eventually became more granular with the implementation of SEMI-OPR
capability.? I had implemented this at Columbia several years earlier
with SC%LOP, or Little Operator capability (this was known colloquially
as l'opr.)? We had a number of training issues with our operators (some
of them literally could not read), so this allowed them to use Galaxy to
mount tapes and paper forms, but nothing more.? PANDA provides
administrator capability (SC%ADM) which allows a certain amount of file
system administration.
The PANDA access control job (ACJ) already puts certain restrictions on
OPERATOR, mainly in the area of login.? It occurred to me that the above
assumptions concerning training simply are not true in the current
hobbyist universe.? You can actually remove OPERATOR (SC%OPR) capability
from the OPERATOR id, which will break a rather large number of things.?
As a matter of fact, you can delete the OPERATOR id entirely.? I'm not
sure you could complete boot up into an sensible state after that; I
guess you'd need to turn on debugging and go directly to KDDT to then
recreate the id by hand. That's training; maybe Monitor Internals level
training...
And of course, even trained individuals can do dumb things... (GUILTY!)?
So I modified the ACJ further to implement the following policies on a
CRDIR% of OPERATOR:
1. May not delete OPERATOR.
2. May not remove SC%OPR from OPERATOR.
3. May not set OPERATOR not login-able
* FILES-ONLY
* INVALID
* CHARGE-LIMITED
4. May not set OPERATOR FTP-ONLY (no way to get to the EXEC; the normal
time-sharing user interface)
5. May not set 'junk' (I.E., undocumented) bits in OPERATOR directory
protection word
6. May not set OPERATOR directory protection to allow world read, write
or connect
7. May not clear the OPERATOR password (set to NUL)
If you're winning enough to defeat these restrictions, then maybe you're
winning enough to understand the ramifications of doing them.
Comments for other DEC OS's?? I don't remember what RSTS, RSX and VMS do.
After working on the DTEKPA issue and coming up with a work around, I
went searching to see if the problem had ever been reported.? In fact,
it had been.?? By me. ? ...Well over a decade ago...
Basically, the default behavior for Tops-20 is to note that a front-end
counter isn't incrementing and--if on the next check it still hasn't
changed--to declare the associated PDP-11 front end down and to initiate
a reboot.? This gives the 11 about a millisecond to get its act together
before the KL whacks it.
Of course, that will never work in KLH10 (see below and previous);
you're hung because the KLH10 DTE emulator doesn't implement code to
simulate a reboot action, so the KL loops forever looking for the
response.? Of course, why would it?? There should be no reason for
Tops-20 to ever think its down.?? Seeing as I like writing assembler
more than C, I decided not to tweak the KLH10 code (I have tweaked it
for other cases and might rethink this).
The workaround is to define some additional functions for the BOOT% JSYS
to set some variables in resident storage in STG and modify DTESRV to
use them.? You can now set an elapsed time to wait before declaring the
PDP-11 down.? I default to five minutes of non-incrementing keep-alive.
Depending on how hard I am beating on things, the front end 'appears' to
go away between anywhere from 5 to 15 seconds.
I think probably the real fix is to not depend on an OS interrupt to
increment the counter.? A thread should be spawned which uses
nanosleep() to bump the counter every 500 microseconds, no matter what
the rest of KLH10 might be doing.? KLH10 is already using multiple forks
for the disks, tape, NI, Etc. (one reason I've preferred it over SimH),
so maybe this won't be a big deal.
> ------------------------------------------------------------------------
> *From*: Mark Crispin <MRC at Lingling.Panda.COM>
> *Subject*: Re: KLH10 front-end reload??
> *To*: Thomas DeBellis <slogin at acedsl.com>
> *Date*: Sun, 29 Nov 2009 11:20:46 -0800 (PST)
> *In-Reply-To*: <4B11CFEA.4020906 at acedsl.com>
> *Message-ID*: <alpine.OSX.2.00.0911291100070.245 at hsinghsing.panda.com>
>
> KLH10 implements enough for the front end DTE protocol for TOPS-20 to
> think that it is talking to a front end, albeit one with just a CTY
> (no KLINIK, DL11 lines, or DECnet).
>
> There is a keepalive timer in both TOPS-20 (to reboot the front end
> when the front end crashes) and in RSX-11F (to reboot TOPS-20 when it
> crashes).
>
> The front end also keeps time well enough to set TOPS-20's clock
> following a crash-reboot; this is superceded in KLH10 as the timebase
> instructions get the time from the host OS.? In addition, Panda
> monitors try to run a program called TIMCHK which will synchronize
> with NTP servers.
>
> So, what happened was that the DTE protocol stopped for some reason.
> TOPS-20 tried to reboot the front end in an attempt to get it going,
> but of course that was futile.
>
> Here's something that may help:
>
> On some Linux systems the esoteric real-time interrupt mechanisms in
> KLH10 don't work well.? So, it may be necessary to set
> KLH10_ITIME_SYNC instead of the default KLH10_ITIME_INTRP. Note that
> doing so will make KLH10 burn much more CPU on the host system.
>
> Usually, though, if you need to do this, it becomes pretty obvious at
> once, with nasty DTE errors from KLH10 shortly after booting (and any
> time you type on the CTY).
>
> One reason why I haven't upgraded Lingling's host CPU is that most of
> the newer machines that I've run KLH10 on have required doing this.?
> It's quite annoying.
>
>> ------------------------------------------------------------------------
>> *From*: Thomas DeBellis <slogin at acedsl.com>
>> *Subject*: KLH10 front-end reload??
>> *To*: Tops-20 Wizards <TOPS-20 at lingling.panda.com>
>> *Date*: Sat, 28 Nov 2009 20:35:38 -0500
>> *Message-ID*: <4B11CFEA.4020906 at acedsl.com>
>>
>> Tommy Timesharing hung earlier today; it had been up over a 175 days.
>> I got an error around 1:27PM-EST that the front end had hung and was
>> rebooted.? By the time I noticed at 4:08, the system was completely
>> wedged.
>>
>> I couldn't get in on the CTY, but KLH10 appeared to be working.
>> However, in the process of poking around, I completely destroyed some
>> information, so I am unable to determine exactly what was going on.?
>> Sigh...
>>
>> As I had been up since early June (and the middle of March before
>> that because of a power failure), this does not appear to be of
>> immediate concern.? The system had not had a single issue during all
>> this time (not even a BUGINF)
>>
>> However ...? Ideas, anyone?? Should I think about getting nervous?? I
>> mean, there IS no front-end on KLH10, right?
>> ________________________________________________________________________
>>
>> ************************************************************************
>> TOPS-20 BUGHLT-BUGCHK
>> ?Logged on Sat 28 Nov 2009 13:27:08????? Monitor uptime was 175 days
>> 19:54:26
>> ????Detected on system # 3699.
>> ????Record sequence number:??? 17527.
>> ************************************************************************
>>
>> Error information:
>> ????Date/Time of error:??? Sat 28 Nov 2009 13:27:05
>> ????Errors since reload:??? 1.
>> ????Fork # & Job #:??????? 777777,777777
>> ????User's logged in dir:??? unknown
>> ????Program name:
>> ????Error:??????????? BUGINF
>> ????Address of error:??? 1137031
>> ????Name:??????????? DTEKPA
>> ????Description:??????? DTE keep alive fail
>> ????CONI APR:??????? 007740,,000003 = No error bits detected
>> ????CONI PAG:??????? 000000,,660151
>> ????DATAI PAG:??????? 700101,,002750
>> ????Contents of ACs:
>> ???????????? 0:??? 000000,,575700
>> ???????????? 1:??? 777777,,000000
>> ???????????? 2:??? 000000,,000000
>> ???????????? 3:??? 000000,,277242
>> ???????????? 4:??? 000100,,206260
>> ???????????? 5:??? 000000,,247445
>> ???????????? 6:??? 000000,,000000
>> ???????????? 7:??? 000000,,000000
>> ??????????? 10:??? 777775,,000002
>> ??????????? 11:??? 000000,,000000
>> ??????????? 12:??? 000000,,614101
>> ??????????? 13:??? 777772,,000012
>> ??????????? 14:??? 777777,,777650
>> ??????????? 15:??? 777305,,353304
>> ??????????? 16:??? 620012,,000000
>> ??????????? 17:??? 777115,,246540
>> ????PI status:??????? 000000,,000175
>> ????Additional data items:??? 1
>> ??????????????? 000000,,000000
>>
>> ????ERA:??????????? 000000,,000000 = word #0 Memory read
>> ????Base phyiscal memory
>> ???? address at failure:??? 0
>>
>> ************************************************************************
>> FRONT END RELOADED
>> ?Logged on Sat 28 Nov 2009 13:28:04????? Monitor uptime was 175 days
>> 19:55:21
>> ????Detected on system # 3699.
>> ????Record sequence number:??? 17528.
>> ************************************************************************
>> ????CPU # :,,Front end #:??? 0,0
>> ????Status at reload:???? No error bits detected
>> ????Retries:??? 3
>> ????Filename for DUMP: <SYSTEM>0DMP11.BIN.1,28-Nov-2009 13:27:05
Hey. Update is virtually exhibiting at the VCF Berlin right now. As a
part of that, there is a tour of Updates stuff and computers, which
people might find amusing.
Among other things, you can see Magica (1.1) (a PDP-11/70) for a while,
up and running on HECnet. You can see the video at
https://wiki.vcfb.de/2020/start?id=en:update
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