[Apologies if this is duplicate, I wasn't sure what list was active and
when]
Thanks for the URL, I'll put it into the enhancement list. I'm still
not sure what I would put into the monitor and what would go into a
light weight (or full) NTP client, but I'll have a think about it.
Passing on to the Department of Pointless Programming, I 'enhanced'
uptime to handle the maximum 70 bit millisecond uptime. It is:
VENTI2 up for 37539161 Millennia, 7 Centuries, 2 Decades, 9 Years, 8
Weeks, 2 Days, 11 Hours, 35 Minutes, 3 Seconds and 423 Milliseconds
So 37 million millennia is .../umm/... well it's a long time. In fact,
at well over two and half times the current age of the universe, it may
even be long enough for politicians to evolve into decent, caring,
thinking individuals.
The math was actually unremarkable, I changed an integer divide
instruction into a routine to handle single (IDIV), double (DIV) and
quadruple intermediate results (DDIV), picking the fastest divide that
wouldn't overflow.
The harder part was rewriting the grammatical routines to properly
inflect plural noun cases. Once you get past Years, English
numerological noun inflection is no longer agglutanive (like Spanish)
but rather fusional, being more akin to Latin and Italian (and
considered 'irregular'). So the routine did the wrong thing.
A little more than half the systems programming staff at Columbia were
bi-lingual, some spoke three or more languages. So it bugged us to see
Unix cop-outs like "1 item(s) processed". I mean, it's a comparison and
conditional transfer; an if statement--barely more than 5 minutes' work.
> ------------------------------------------------------------------------
> On 1/20/22 5:21 PM, Peter Lothberg wrote:
>
> Time....
>
>> Not quite. The acronym actually says that it is not solar time, it's
>> Greenwich MEAN Time. UTC is merely the new name for GMT, obviously
>> adopted to keep the French from fulminating.
>
> GMT was established by the Greenwich observatory observing the sun.
>
> When the atomic second was created the target was the year 1900 GMT
> second.
>
> GMT is based on earth position, and it's modern equivalent is UT1,
> when UTC and UT1 differs more than 0.92 sec
>
> we do leap seconds.
>
> https://www.iers.org/IERS/EN/Science/EarthRotation/UT1LOD.html
>
> UTC is based on a constant running timescale based on the frequency of
> CS133 oscillating between two
>
> hyper fine states.
>
> So the difference between GMT and UTC can be almost a second, and
> there is no system that
>
> distributes GMT, BTP, GPS etc are all UTC based.
>
> -P
>
I have created a T1.1 (beta) branch of PyDECnet, which seems to be working well enough to take for a trial run. I currently have it running as the HECnet mapper node (28NH). That's not a major stress test since it's an end node.
Assuming things go well I'll switch PYTHON, the area 41 backbone router, to this version in a couple of days.
If anyone wants to try this, you can find the code at svn://akdesign.dyndns.org/pydecnet/branches/t1.1/pydecnet -- in other words, same Subversion server but at the branches/T1.1 subtree rather than trunk. Be sure to read CHANGES.txt, there are some small changes to the config files. And if you use the API (HTTP GET or POST to /api, in V1.0) you'll need to make changes; I dropped that approach since it wasn't workable going forward. The replacement is actually much easier and there are some support modules ("connectors") to simplify things further. See doc/api.txt for details.
paul
Ok, it's highly unlikely that anyone cares, but just in case I am
posting this anyway.
When using RSX-11M-Plus, if you write a program that uses the
Datatrieve-11 callable interface over DECnet, your program cannot use
DECnet itself for anything in parallel. Which sucks. I've just done some
changes to the Datatrieve-11 call interface library, so that this is now
possible to do. Ping me if you want to know more.
I've also written a nice interface from PDP-11 C, which makes it pretty
easy to use both Datatrieve-11 and DECnet.
The weird things I amuse myself with, 20 years after anyone stopped caring.
I should probably start writing somekind of manual with how to do these
things that are not obvious, might not be documented, or that I might
have fixed over the years...
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,
Apologies if I caused some bounces or timeouts with messages. Cassini.dfupdate.se is in the 'Hetzner' 65.108.0.0/15 subnet. Seemingly large swathes of that part of the Internet have a very low reputation in terms of port scanners, spammers, brute force attackers, sources of DOS attacks etc.. I've made exceptions.
Keith
Check it out:
@_uptiME.EXE.2_
TOMMYT up for 1 Year, 2 Days, 16 Hours, 36 Minutes, 26 Seconds and
582 Milliseconds
@_timET2.EXE.4 _
Tops-20 was booted on Saturday, January 16, 2021 8:46:38PM-EST.
It will crash with an UP2LNG BUGHLT on Friday, February 18, 2022
1:08:57PM-EST.
@
UPTIME and TIMET2 are two programs that I wrote several years; ago,
UPTIME in 2017 and TIMET2 in 2006.? I wrote them because I found the
hours format given by SYSTAT SYSTEM and INFORMATION MONITOR-STATISTICS
to be a little opaque and they didn't have the information I wanted, viz:
@_sysTAT sySTEM_
?Tue 18-Jan-2022 13:28:45? Up *8800:42:07!!!!!!!!*
?4+7 Jobs?? Load av?? 0.01?? 0.02?? 0.02
?No operator in attendance
@_iNFORMATION (ABOUT) monITOR-STATISTICS_
?Up *8800:42:10!!!!!!!!*
?Idle 99%? Waiting 0%? Sched ovh 0%? Pager traps 0%
?Swap reads 28049 Writes 385176? File reads 4643699 Writes 3677925
?8092 Pages of user memory
?4259771001 Term wakeups? 1255 Term interrupts
?NBAL av?? 0.32? NRUN av?? 0.02
?Runtime of jobs on sched queues 0-6 (sec)
?? ?143964??? 16409??? 14494??? 1012??? 1756 4846??? 4215
@
I wrote TIMET2 because I needed to know when to set a shutdown. If you
don't do that and you hit the uptime limit, then the machine simple
crashes with an UP2LNG BUGHLT. This happens because the uptime
millisecond counter is a signed 36 bit integer, which will roll over and
become negative after 1 Year, 4 Weeks, 5 Days, 16 Hours, 22 Minutes, 18
Seconds and 367 Milliseconds.? You would think the code would self-set a
'graceful' shutdown, but it doesn't...? Maybe I'll do that one of these
days; it's easy enough.
Since the PDP-10 does not have unsigned compares, fixing this would
involve changing a rather large number of comparisons. Assuming you kept
the storage at a single word, going unsigned would get you out to 2
Years, 9 Weeks, 4 Days, 8 Hours, 44 Minutes, 36 Seconds and 735
Milliseconds.? That's probably still not that great given today's hardware.
Going to an unsigned double word format would obviously get you a far
larger uptime.? However, the current arithmetic that I use can 'only'?
handle a maximum uptime of 34,359,738,367,999 of milliseconds.? This
works out to be 1092 Years, 27 Weeks, 5 Days, 3 Hours, 46 Minutes, 7
Seconds and 999 Milliseconds.? Since the time of day counter expires in
7-Aug-2576 7:59:59 PM EDT, I used a faster instruction...? Otherwise,
going over a millennium between reboots seemed reasonable unless you
find yourself in a significantly sub-luminal spacecraft going someplace
inter-galactic...
I know that XKL fixed at least part of the uptime problem, but I don't
remember what that limit is.? What are the limits for other systems?
It runs on later Windows versions as long as they are 32-bit.Kari
-------- Original message --------
From: Johnny Billquist <bqt at softjar.se>
Date: 1/16/22 02:54 (GMT+02:00)
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] KINET by KI Research - DECnet for numerous Unix flavors
and OS/2?
On 2022-01-15 20:03, Thomas DeBellis wrote:> That jogs a memory about a question I had; I don't suppose there's > anything for Windows 7, 10 or Mac OS X?Have anyone tried DEC Pathworks on newer windows? I have it running on XP.?? Johnny> > On 1/13/22 12:20 PM, Dave McGuire wrote:>> On 1/13/22 5:07 AM, Supratim Sanyal wrote:>>>> Now, that name sounds very familiar! That might have been who I was >>>> talking to.>>>>>> He responded? saying the KiNET build-tree supports 55 vendor >>> platforms and he will look at what needs to be done to make the build >>> tree available.>>>>>> Probably similar response received by Tim.>>>>>> Let?s wait.>>>> ? Thanks for pursuing this.? This is very exciting!>>>> ???????? -Dave>>-- Johnny Billquist????????????????? || "I'm on a bus?????????????????????????????????? ||? on a psychedelic tripemail: bqt at softjar.se???????????? ||? Reading murder bookspdp is alive!???????????????????? ||? tryin' to stay hip" - B. Idol
Once upon a time there seems to have been a company called KI Research
at Columbia, Maryland. Circa 1994 they had for sale something called
KINET DNA which apparently was a user-mode DECnet stack available for
numerous Unix flavors and OS/2 (maybe more operating systems). I came
across the name looking for a DECnet implementation for HP-UX.
Here's one of the threads from 1993 (!) that I am looking at:
http://www.verycomputer.com/30_4d016ca71ca3072b_1.htm
Does anyone here have pointers to some archive which might have
distributions of KINET?
Thanks
Supratim
Time for a new release announcement of TCP/IP for RSX-11M-PLUS.
This is version 2.9 of BQTCP/IP.
It's been three weeks since the last official update, which is rather
short. But there are two significant things that been solved since the
last release, which is motivation for a release so shortly after the
previous one.
Highlights:
. Bugfix in name resolved that could cause system crashes under some
conditions.
. Improvements to DECnet performance.
Detailed information on things that have been done since the last release:
TCP:
. Improved the handling when both sides sends FIN at the same time.
DNS:
. Bugfix in resolver. Under the wrong conditions, the system could
crash. It was a combination of failing DNS, short timeouts on the query
itself, and a race condition in the code in this case. So the chances of
hitting it were extremely low, but it can happen.
MAIL:
. Improve handling of hosts with no reverse dns, or giving fake
information or trying to do weird commands. Such hosts are not blocked
anymore, but are tracked, and only mails to postmaster from such hosts
are accepted (this is more in accordance with the relevant RFCs).
. Added postmaster sending a warning mail when mail delivery isn't
immediately successful, to make people aware that there might be problems.
. Improved mail queue processing, making the mail queue not be locked
for longer periods.
TELNETD:
. Improved connection tracking.
FTPD:
. Add logging of whether transfers completed successfully or not in logs.
IPC library:
. Bugfix. The _notify() function didn't work right.
RSX:
. Added patched ECL module for DECnet to improve performance.
Some additional notes:
As usual, I would recommend people to update as soon as possible.
The changes are not critical, but will lead to a much better experience,
and might avoid system crashes in rare circumstances.
The patches to the TT: driver cannot be applied automatically, but
requires users to apply the patches themselves, and then run SYSGEN to
generate a new system.
Once added, the TNC2 task can be run at login, and will define logical
names for the user telling where he is connected from, if using telnet.
The TT: driver patches also allows the updated MCR to give more
information with the DEV command (SHOW TERMINAL in DCL).
The other patches to RSX can be applied automatically by IPGEN, either
if used interactively when answering YES to the question about applying
RSX patches, or by running IPGEN explicitly to do the patches, with the
command:
@IPGEN PATCH
Specific information about the patches:
LAT: Fixes a memory leak, and adds the ability to read where a terminal
connection comes from when using LAT, using SF.GMC.
RMSDAP: Fixes a bug in getting the file protection, so the XAB gets
filled in correctly for remote files.
RMSDSP: Fixes that some numbers were displayed in signed octal, which
should have been displayed in decimal or unsigned octal, depending on
number.
DCL: Added terminal attributes for COLOR.
MCR: Too many fixes to be listed here...
ECL: If the receiving machine is very slow, and the sending machine is
very fast, and the receiver announce several large buffers available,
ECL cannot keep up, but drops packets. This is sortof a problem with the
DECnet flow control, as it is used in RSX. The simple solution is to
allow more outstanding buffers when receiving. A more complex solution
would be to change how RSX DECnet do flow control, but that would
require rewriting a fair chunk of the ECL module.
As usual, the distribution is available from:
ftp://mim.update.uu.se/bqtcp.dsk
ftp://mim.update.uu.se/bqtcp.tap
!!! BQTCP is also available through RPM !!!
(As an additional note, if there are any problems communicating with Mim
using port 21, the ftp service is also available at port 10021)
The documentation is also available through ftp on Mim, or also at
http://mim.update.uu.se/tcpipdoc
I hope people find this update useful.
On a final note, Mim have moved. Mim.Update.UU.SE still points to the
machine, but the actual name is now Mim.Stupi.NET, and in case
Update.UU.SE cease to work at some point, Stupi.NET should still be fine.
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
With help from Mark Pizzolato, I added support to SIMH for my DDCMP sync line interface ("DDCMP framer"). This is a USB device, built around a Raspberry Pico, that implements the lower layers of the DDCMP synchronous line protocol. It allows SIMH (or PyDECnet) to talk to real machines that use those interfaces.
My ability to test with real hardware is limited; in particular I don't have any coax cable ("integral modem") devices like the DMC-11/AL. But I did test RS232 mode with my Pro 380.
The current SIMH on Github includes the necessary code and documentation to allow the use of this device as an emulated DUP, KMC-DUP, or DMC. The current PyDECnet (on my Subversion server) also supports it, and the two will interoperate as you would expect.
The design for the device is open source, it can be found on github: https://github.com/pkoning2/ddcmp . At the moment if you want one of these you'll have to build it; I provide the design files but not boards or devices, and I don't plan to. But of course since it's open others may do so if they wish.
I'd be very interested in test results of the coax interface since I could only test that against the device itself and against the documentation.
paul
Hi,
Just noticed:
ncp tell a1rtr show known circ stat
The above shows a circuit ETH-10 adjacent to node 5.1023.
It looks like none of the area routers I've looked at actually see the area, ie: a29rt2, a1rtr, python.
Needless to say that 5.* is unreachable from my point of view.
FYI
Keith