14 Apr
2021
14 Apr
'21
4:07 a.m.
For anyone running PyDECnet, I would recommend you update to the latest
version (582), since that removes a behavior that triggered BQTCP to
sometimes automatically block PyDECnet hosts.
And of course, it you're running something way older, there are probably
other improvements you'll also benefit from.
And thanks to Paul Koning, who wrote this nice piece of software.
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
14 Apr
14 Apr
4:29 p.m.
Thanks Johnny.
When installing upgrades of PyDECnet, be sure to review the file CHANGES.txt which is in
the top level directory of the repository. It doesn't show all the changes
(that's what the Subversion log is for); instead, it calls out changes that are
user-visible, for example changes in how the config files are used.
paul
On Apr 13, 2021, at 10:07 PM, Johnny Billquist <bqt
at softjar.se> wrote:
For anyone running PyDECnet, I would recommend you update to the latest version (582),
since that removes a behavior that triggered BQTCP to sometimes automatically block
PyDECnet hosts.
And of course, it you're running something way older, there are probably other
improvements you'll also benefit from.
And thanks to Paul Koning, who wrote this nice piece of software.
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
4:55 p.m.
How about a hint? Did you change something that's not backward
compatible?
Bob
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf
Of Paul Koning
Sent: Wednesday, April 14, 2021 7:29 AM
To: hecnet at update.uu.se
Subject: Re: [HECnet] PyDECnet
Thanks Johnny.
When installing upgrades of PyDECnet, be sure to review the file CHANGES.txt
which is in the top level directory of the repository. It doesn't show all
the changes (that's what the Subversion log is for); instead, it calls out
changes that are user-visible, for example changes in how the config files
are used.
paul
On Apr 13, 2021, at 10:07 PM, Johnny Billquist <bqt
at softjar.se> wrote:
For anyone running PyDECnet, I would recommend you update to the latest
version
(582), since that removes a behavior that triggered BQTCP to
sometimes automatically block PyDECnet hosts.
And of course, it you're running something way older, there are probably
other
improvements you'll also benefit from.
And thanks to Paul Koning, who wrote this nice piece of software.
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
5:30 p.m.
Ok, I'll bite - either I'm missing something or you're being overly
cautious. I just checked out version 582 and the last change reported in
the CHANGES.txt file is for version 575. Is it safe to say there are no
significant incompatibilities in this version?'
Thanks,
Bob
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf
Of Paul Koning
Sent: Wednesday, April 14, 2021 7:29 AM
To: hecnet at update.uu.se
Subject: Re: [HECnet] PyDECnet
Thanks Johnny.
When installing upgrades of PyDECnet, be sure to review the file CHANGES.txt
which is in the top level directory of the repository. It doesn't show all
the changes (that's what the Subversion log is for); instead, it calls out
changes that are user-visible, for example changes in how the config files
are used.
paul
7:21 p.m.
Correct.
I'm sorry, I guess I made things confusing. My comment was in response to
Johnny's observation that those upgrading from long-ago versions would also see a
bunch of other improvements and new features. Yes, but also if you go back far enough you
may need to tweak your DECnet config file.
I should have been more explicit. And I'll also try to make sure that when I put out
a new version that does include a need to change any settings or the like (i.e., something
worthy of a CHANGES.txt entry) it will go out with a note in the annoucement saying so.
In other words, you should be able to rely on "if I didn't say anything to the
contrary, a new version is compatible with the previous".
paul
On Apr 14, 2021, at 11:30 AM, Robert Armstrong <bob
at jfcl.com> wrote:
Ok, I'll bite - either I'm missing something or you're being overly
cautious. I just checked out version 582 and the last change reported in
the CHANGES.txt file is for version 575. Is it safe to say there are no
significant incompatibilities in this version?'
Thanks,
Bob
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf
Of Paul Koning
Sent: Wednesday, April 14, 2021 7:29 AM
To: hecnet at update.uu.se
Subject: Re: [HECnet] PyDECnet
Thanks Johnny.
When installing upgrades of PyDECnet, be sure to review the file CHANGES.txt
which is in the top level directory of the repository. It doesn't show all
the changes (that's what the Subversion log is for); instead, it calls out
changes that are user-visible, for example changes in how the config files
are used.
paul
16 Apr
16 Apr
3:41 p.m.
Hi,
A general point about pyDECnet usage. I leave the default 'Identification' string
alone so that anybody interested can discover the version of pydecnet being used (SHOW
EXEC CHAR). I have noticed that others tend to personalise the string, often removing that
version number. Would it be possible to append your personalisation to the version rather
than replace it? From a trouble-shooting point of view, knowing that two routers connected
by a circuit are either same version or vastly different often helps.
Just a thought.
Keith
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of
Robert Armstrong
Sent: 14 April 2021 18:39
To: hecnet at Update.UU.SE
Subject: RE: [HECnet] PyDECnet
Correct.
Thanks, Paul. I just upgraded A2RTR. Seems to work on my end. If anybody has any
problem with it, let me know.
Bob
4 p.m.
On Apr 16, 2021, at 9:41 AM, Keith Halewood
<Keith.Halewood at pitbulluk.org> wrote:
Hi,
A general point about pyDECnet usage. I leave the default 'Identification' string
alone so that anybody interested can discover the version of pydecnet being used (SHOW
EXEC CHAR). I have noticed that others tend to personalise the string, often removing that
version number. Would it be possible to append your personalisation to the version rather
than replace it? From a trouble-shooting point of view, knowing that two routers connected
by a circuit are either same version or vastly different often helps.
Just a thought.
Keith
Interesting idea. Strictly speaking, that string is rather short, though some other
DECnet implementations send oversized values.
Another option would be to have the version information be a separate read-only parameter,
that would be easy.
paul
4:57 p.m.
Keith Halewood <Keith.Halewood at pitbulluk.org>
wrote:
.. append your personalisation to the version rather than replace it?
If I understand correctly, that would make it necessary to edit your
config file every time you upgrade pyDECnet. Updates are not uncommon and
I'd find that really annoying.
A separate parameter with the version would be fine with me.
Bob
6:13 p.m.
A separate version parameter would work fine for me.
Wilm
-----Original Message-----
From: owner-hecnet at Update.UU.SE <owner-hecnet at Update.UU.SE> On Behalf Of
Robert Armstrong
Sent: Friday, April 16, 2021 4:57 PM
To: hecnet at Update.UU.SE
Subject: RE: [HECnet] PyDECnet
Keith Halewood <Keith.Halewood at pitbulluk.org>
wrote:
.. append your personalisation to the version rather than replace it?
If I understand correctly, that would make it necessary to edit your
config file every time you upgrade pyDECnet. Updates are not uncommon and
I'd find that really annoying.
A separate parameter with the version would be fine with me.
Bob
7:19 p.m.
On Apr 16, 2021, at 10:00 AM, Paul Koning
<paulkoning at comcast.net> wrote:
Done. It turns out a suitable parameter already exists in the standard, parameter 126,
"Software identification". As of rev 583 that will report the PyDECnet version
number.
paul
On Apr 16, 2021, at 9:41 AM, Keith Halewood
<Keith.Halewood at pitbulluk.org> wrote:
Hi,
A general point about pyDECnet usage. I leave the default 'Identification' string
alone so that anybody interested can discover the version of pydecnet being used (SHOW
EXEC CHAR). I have noticed that others tend to personalise the string, often removing that
version number. Would it be possible to append your personalisation to the version rather
than replace it? From a trouble-shooting point of view, knowing that two routers connected
by a circuit are either same version or vastly different often helps.
Just a thought.
Keith
Interesting idea. Strictly speaking, that string is rather short, though some other
DECnet implementations send oversized values.
Another option would be to have the version information be a separate read-only
parameter, that would be easy.
7:42 p.m.
And ONAPI4:: (29.206) is now running that version, splendid!
Wilm
-----Original Message-----
From: owner-hecnet at Update.UU.SE <owner-hecnet at Update.UU.SE> On Behalf Of
Paul Koning
Sent: Friday, April 16, 2021 7:20 PM
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] PyDECnet
some
other DECnet implementations send oversized values.
On Apr 16, 2021, at 10:00 AM, Paul Koning
<paulkoning at comcast.net> wrote:
> On Apr 16, 2021, at 9:41 AM, Keith Halewood
<Keith.Halewood at
pitbulluk.org> wrote:
>
> Hi,
>
> A general point about pyDECnet usage. I leave the default
'Identification' string alone so that anybody interested can discover the
version of pydecnet being used (SHOW EXEC CHAR). I have noticed that others
tend to personalise the string, often removing that version number. Would it
be possible to append your personalisation to the version rather than
replace it? From a trouble-shooting point of view, knowing that two routers
connected by a circuit are either same version or vastly different often
helps.
Just a thought.
Keith
Interesting idea. Strictly speaking, that string is rather short, though
Another option would be to have the version information be a separate
read-only
parameter, that would be easy.
Done. It turns out a suitable parameter already exists in the standard,
parameter 126, "Software identification". As of rev 583 that will report
the PyDECnet version number.
paul
7:46 p.m.
Same here on both a29 routers.
Thanks Paul.
On 16 Apr 2021, at 18:43, Wilm Boerhout <wboerhout
at gmail.com> wrote:
?And ONAPI4:: (29.206) is now running that version, splendid!
Wilm
-----Original Message-----
From: owner-hecnet at Update.UU.SE <owner-hecnet at Update.UU.SE> On Behalf Of
Paul Koning
Sent: Friday, April 16, 2021 7:20 PM
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] PyDECnet
some
other DECnet implementations send oversized values.
> On Apr 16, 2021, at 10:00 AM, Paul Koning
<paulkoning at comcast.net> wrote:
>
>
>
> On Apr 16, 2021, at 9:41 AM, Keith Halewood
<Keith.Halewood at
pitbulluk.org> wrote:
>
> Hi,
>
> A general point about pyDECnet usage. I leave the default
'Identification' string alone so that anybody interested can discover the
version of pydecnet being used (SHOW EXEC CHAR). I have noticed that others
tend to personalise the string, often removing that version number. Would it
be possible to append your personalisation to the version rather than
replace it? From a trouble-shooting point of view, knowing that two routers
connected by a circuit are either same version or vastly different often
helps.
Just a thought.
Keith
Interesting idea. Strictly speaking, that string is rather short, though
Another option would be to have the version information be a separate
read-only
parameter, that would be easy.
Done. It turns out a suitable parameter already exists in the standard,
parameter 126, "Software identification". As of rev 583 that will report
the PyDECnet version number.
paul
7:58 p.m.
GLDRTR:: (2.699) is running the new version now. Yay!
--
Mark J. Blair, NF6X <nf6x at nf6x.net>
https://www.nf6x.net/
10:17 p.m.
On 2021-04-16 19:19, Paul Koning wrote:
Way cool. And RSX even supports it. That was nice!
.ncp tell python sho exec cha
Node characteristics as of 16-APR-21 22:14:59
Executor node = 41.1 (PYTHON)
Identification = DECnet/Python, New Boston, NH, USA, Management
version = 4.0.0
Software identification = DECnet/Python V1.0-583, Incoming timer = 30
Outgoing timer = 30, NSP version = 4.0.0
Maximum links = 4095, Delay factor = 32
Delay weight = 3
Inactivity timer = 300, Retransmit factor = 5
Routing version = 2.0.0, Type = Area
Maximum area = 63, Area maximum cost = 128
Area maximum hops = 16
Segment buffer size = 576
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
On Apr 16, 2021, at 10:00 AM, Paul Koning
<paulkoning at comcast.net> wrote:
Done. It turns out a suitable parameter already exists in the standard, parameter 126,
"Software identification". As of rev 583 that will report the PyDECnet version
number. On Apr 16, 2021, at 9:41 AM, Keith Halewood
<Keith.Halewood at pitbulluk.org> wrote:
Hi,
A general point about pyDECnet usage. I leave the default 'Identification' string
alone so that anybody interested can discover the version of pydecnet being used (SHOW
EXEC CHAR). I have noticed that others tend to personalise the string, often removing that
version number. Would it be possible to append your personalisation to the version rather
than replace it? From a trouble-shooting point of view, knowing that two routers connected
by a circuit are either same version or vastly different often helps.
Just a thought.
Keith
Interesting idea. Strictly speaking, that string is rather short, though some other
DECnet implementations send oversized values.
Another option would be to have the version information be a separate read-only
parameter, that would be easy.
10:23 p.m.
Neat! I didn't know how to do that. It works nicely in VMS 7.3:
$ ncp tell gldrtr sho exec cha
Node Volatile Characteristics as of 16-APR-2021 13:21:17
Executor node = 2.699 (GLDRTR)
Identification = GLDRTR PyDECnet Router for NF6Xnet 2.600-2.699
Management version = V4.0.0
Software identification = DECnet/Python V1.0-583
Incoming timer = 30
Outgoing timer = 30
NSP version = V4.0.0
Maximum links = 4095
Delay factor = 32
Delay weight = 3
Inactivity timer = 300
Retransmit factor = 5
Routing version = V2.0.0
Type = routing IV
Routing timer = 600
Broadcast routing timer = 10
Maximum address = 1023
Maximum cost = 128
Maximum hops = 16
Maximum visits = 32
Segment buffer size = 576
--
Mark J. Blair, NF6X <nf6x at nf6x.net>
https://www.nf6x.net/
10:26 p.m.
I'm tempted to throw this in for DECnet/RSX. Just because it would be
cool. :-)
Johnny
On 2021-04-16 22:23, Mark J. Blair wrote:
Neat! I didn't know how to do that. It works
nicely in VMS 7.3:
$ ncp tell gldrtr sho exec cha
Node Volatile Characteristics as of 16-APR-2021 13:21:17
Executor node = 2.699 (GLDRTR)
Identification = GLDRTR PyDECnet Router for NF6Xnet 2.600-2.699
Management version = V4.0.0
Software identification = DECnet/Python V1.0-583
Incoming timer = 30
Outgoing timer = 30
NSP version = V4.0.0
Maximum links = 4095
Delay factor = 32
Delay weight = 3
Inactivity timer = 300
Retransmit factor = 5
Routing version = V2.0.0
Type = routing IV
Routing timer = 600
Broadcast routing timer = 10
Maximum address = 1023
Maximum cost = 128
Maximum hops = 16
Maximum visits = 32
Segment buffer size = 576
--
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
1347
days inactive
1349
days old
16 comments
6 participants
participants (6)
-
bob＠jfcl.com -
bqt＠softjar.se -
Keith.Halewood＠pitbulluk.org -
nf6x＠nf6x.net -
paulkoning＠comcast.net -
wboerhout＠gmail.com