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
Area 60 is back online, things have cooled back down, and the max temp for the next 10 days is only supposed to be about 80F.
The bad news is, I lost a Hard Drive. The good news is, it was the drive with my backups.
Zane
Hail all you RSTS buffs!
One of my nodes (PIRSTS) is running RSTS V10.1L and DECnet V4.1
Ever since I am on HECnet, I have observed that job slots are filled over
time with jobs under the DECnet account [29,206] in HB state, up to the
point that the job max is reached, and I cannot log in anymore.
My working hypothesis is that the polling processes (for HECnet mapping and
other inquiring minds - you know who you are) keep creating new jobs,
instead of reusing old ones.
Is there a way to tell DECnet/E that it should not keep jobs in HB state,
but log them out after use? Or reuse existing jobs on incoming connection
requests? On DECnet/VMS there are timer and other logicals that steer this
behavior.
Running a daily kill job seems, well, overkill.
Thanks,
Wilm
I've discovered that three of my four RA8x drives have failed due to bad
tachometer optical sensors. Apparently the material these guys were potted
with decades ago gradually turns opaque and, being as they're "optical",
that's Really Bad. Has anybody else had this issue? Anybody found a
replacement for them? It's just an IR LED and a phototransistor in a fancy
plastic housing, and that's still pretty common devices these days. I just
need one that's mechanically compatible with the RA8x HDA. A modern
production replacement seems like a better plan than a new old stock
replacement since any old production ones are just as likely to be bad.
Bob
Is anyone who's familiar with pyDECnet configuring available on a
communication system that's less async than email? I've got Matrix, IRC,
Discord, and Slack as well as WhatsApp and Signal available to me.
Thanks!
-brian
I thought I'd share an example of a non-optimal setup for people, so
that you can understand a little better what we currently have.
This is from area 1 to area 34. More specifically ANKE to area 34.
Now, physically, ANKE is in Stockholm, Sweden, while A34RTR is in
BÃ¥tbyggartorp, Sweden. They are actually not that far from each other,
physically, if you look on a map. Maybe 40 kilometers at the most.
However, in HECnet, it is 3 hops, and a cost of 20.
Now, when ANKE wants to talk to area 34, the next hops are:
PYTHON - New Boston, NH, USA (cost 8)
IMPRTR - Washington DC, USA (cost 4)
and then I *think* it must be A34RTR, since that should be the final
hop, but since both IMPRTR and A34RTR are Cisco boxes, I can't see.
And a guess that the cost of that last hop would be 8.
But clearly, such a roundabout way to talk to such a close node is
kindof silly. :-) We should have reasonable links, in reasonable
directions, and with appropriate costs, so that we don't have things
like this. No good reason to. It's not like we need to pay money to have
physical cables installed between places.
(This must have been such a fun work back in the day when you needed to
actually pay for the physical cables...)
If the link to PYTHON went down, the alternative route would be through
A39RTR(9), PYRTR(2), IMPRTR(4) and then A34RTR. The costs in
parenthesis. (A cost of 2 between A39RTR and PYRTR seems rather cheap,
but what do I know?)
A few suggestions on how to look at things:
If you have a machine that talks NICE, you can examine for both VMS, RSX
and PyDECnet, what the next hop towards an area is. Giving examples on MIM:
.ncp tell anke sho area 34 stat
Area status as of 10-SEP-22 15:34:49
Next
Area State Cost Hops Circuit Node
34 Reachable 20 3 DMC-15 41.1 (PYTHON)
.ncp tell anke sho cir dmc-15 cha
Circuit characteristics as of 10-SEP-22 15:36:02
Circuit = DMC-15
Level one cost = 8
Hello timer = 60, Listen timer = 630
This can then be repeated for node PYTHON and so on. But as noted, when
you get to a Cisco box, you can't do this. Cisco boxes do not speak NICE.
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
