Hi Wilm,

Thanks for that. I’m using a module imported during pydecnet startup. See attached. The config line in the router conf file is:

object --name timestamp --module decnet.modules.timestamp

Keith

From: Wilm Boerhout [mailto:wboerhout@gmail.com]
Sent: 15 June 2024 17:30
To: 'The Hobbyist DECnet mailing list' <hecnet@lists.dfupdate.se>
Subject: [HECnet] Re: PyDECnet additional network objects

Keith,

Great minds think alike 😊

I have done a similar thing a while ago. See attachment, modeled on one of the other templates in Pauls’distribution.

Wilm

From: Keith Halewood <Keith.Halewood@pitbulluk.org>
Sent: Saturday, June 15, 2024 5:26 PM
To: The Hobbyist DECnet mailing list <hecnet@lists.dfupdate.se>
Subject: [HECnet] PyDECnet additional network objects

Hi,

I’m including this in HECnet because it might be of general interest.

I have been creating the odd object here and there on a test router, using the mirror.py application class as a starting example, for listening to and talking to VMS processes that have opened up a task connection to them.

I can do something like:

$ open/read/write fio node::”=TIMESTAMP”

$ write fio “UTC”

$ read fio ts

$ close fio

$ show sym fio

The object waits for a message – the timezone required – and then returns  with a message containing the VMS time string in the form dd-mmm-yyyy:hh:mm:ss.cc

It all work very well.

The dispatch method in the pydecnet application class code sends an accept when it gets a connect and then sends a message containing the timestamp when it receives a data message containing the timezone required.

A simpler version of this, in which the timestamp in UTC is sent immediately without waiting for a timezone string, would not work. I was trying to execute a conn.send_data(…) immediately after a conn.accept() and getting a ‘WrongState’ exception there and then. What am I missing?

Regards

Keith