Create Message during thread startup?

Mark,

What context is the proc running in, and is it on the Inbound or Outbound thread?  What disposition are you setting the message to, and are you appending to the disposition list?

Jim Cobane

Henry Ford Health

We have code that does something similiar in our startup.  Here is the code fragment that was setup by a previous programmer.  I was told that the engStartupSwitchThrow command to use was provided by QDX support when they where researching it but it does not appear to be documented anywhere.  But this does work for use.  We place the tps in our outbound connection. Hope it helps.

Mark and company,

The secret command is buried in the documentation – I played it with once a long time ago and figured it was interesting but we had no use for it at the time.  Being that this is the Cloverleaf community, I figured it was ok to post the documentation – hopefully this is helpful (the command is bolded).

Enjoy.

Protocol Start-Up Switch

The protocol start-up switch is used to control how protocol messages received from the protocol driver are routed. At thread start-up, a Tcl procedure (if defined) is given control of message flow. It is called once to allow it to set up its initial state. It is then called each time a new protocol message arrives from the connection. The procedure is given the message and it has the option to do whatever it wants with it.

Each time the procedure is called-including the initial call-the return value from the procedure is a list of binary object handles wrapped inside two keyed lists. The first list indicates binary objects that should be written to the connection. The second list indicates binary objects that should be moved to the inbound pre-SMS queue. The reason for the second list is to give the Tcl procedure the opportunity to “pass along” protocol messages that it receives that are uninteresting to it.

While the procedure is running, it has access to the inbound pre-SMS stack. It may remove messages from the queue using Tcl built-in functions. This functionality is provided so it may remove messages that have not yet entered inbound SMS processing.

Once the procedure is done controlling the start-up flow, it toggles the protocol switch from within Tcl. Once the procedure returns arter it has thrown the switch, the procedure will not be called again until the thread is restarted.

Note:   The protocol start-up switch is thrown using the engine-only Tcl command engpswthrow. This is required for normal processing. Otherwise, the thread stays in Startup mode.

Robert,

 I found that too, it had my head scratching.  I’m not sure why QDX support told our programmer to use that other command I listed, but it only seems available from within the hciengine process.  

  Can anyone from Healthvision chime in about the engStartupSwitchThrow command and is it the same as the engpswthrow command?  

One note is that we have been using this proc since 3.8 but the engpswthrow has been available since then also, so I don’t know why we where told to use the other undocumented command.

engpswthrow and engStartupSwitchThrow are both legitimate commands and accomplish the same thing.  The engpswthrow was added to make the name shorted and easier to remember.  The engStartupSwitchThrow command was left for backward compatibility.

There are other nuances you have to consider when writing a protocol startup procedure especially in the run mode.  You must check the context of any received message or you may be getting a copy of the message you sent.

When you send a message in protocol startup, the first thing you will see is a message in the context “proto_startup_sendok” – we almost never see “proto_startup_sendfail”.  Any response received will be in the context “proto_startup”

Until the “magic” switch is thrown it is as if the thread does not exist as everything is controlled by the protocol startup proc.  Once the switch is thrown, it is as if the proc no longer exists.

I hope this helps

I was getting that impression also from the docs.  It looks like it is only needed for the protocol start-up procedure tps. I think I was getting the start section of the tps confused with the start-up procedure.  So, I’m assuming it is not needed in the start section of any tps unless that tps is being used as a protocol start-up procedure.

Glad things are working for you.

I was getting that impression also from the docs.