On comparison, I seem to recall that I did put my response after a data received message, and not immediately after the connect acknowledge.

 

It is always tricky to reverse engineer someone else’s handywork.

 

Wilm

 

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

 

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