Create Message during thread startup?

[Mark Thompson]

Clovertechies,

I have an application that would like to receive a specific startup message whenever we bring up our Cloverleaf connection.

Sounds easy, I thought — just take all the message creation logic I normally use in the run section and move it up to the start section of my tps proc.  I even remembered the normal gotcha’s like set the SOURCECONN to the current thread so the process doesn’t hang & set the DESTCONN to the current thread so the message has somewhere to go.

With the engine noise turned up all the way, I can see that the messasge is created but never sent.  It’s message ID is freed as soon as the tps processing completes.

Does someone know the magic formula to get a message sent from the startup tps on an outbound thread?

- Mark Thompson
HealthPartners

Topic

[James Cobane]

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

[John Mercogliano]

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.

Code:

set mh [msgcreate -type data ““]

# incase you want to wait for a reply
msgmetaset $mh FLAGS { {expect_reply TRUE} }

# the engine start-up switch must be thrown to get the message to the TPS Queue
engStartupSwitchThrow

lappend dispList “PROTO $mh”

John Mercogliano
Sentara Healthcare
Hampton Roads, VA

[Mark Thompson]

Thanks John — that’s what I’m looking for.  I’ll follow up with support on how to throw the engine start switch.

- Mark Thompson
HealthPartners

[Bob Richardson]

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.

[John Mercogliano]

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.

John Mercogliano
Sentara Healthcare
Hampton Roads, VA

[Charlie Bursell]

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

[Mark Thompson]

Thanks to all for your comments and suggestions.

I’m working on an outbound thread in CL 5.6.  Things may work differently for inbound threads, but here’s what I found.

In the “start” section of my tps proc I msgcreate a message, msgmetaset the SOURCECONN and DESTCONN to the thread name and lappend PROTO the message disposition list.  The message is logged in the outbound SMAT file and sent to the downstream application.  It did not require the use of engpswthrow.  (But I really appreciate knowing about engpswthrow because it may be of use with inbound threads.)

- Mark Thompson
HealthPartners

[John Mercogliano]

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.

John Mercogliano
Sentara Healthcare
Hampton Roads, VA

[Rob Abbott]

John Mercogliano wrote:

I was getting that impression also from the docs.

Rob Abbott
Cloverleaf Emeritus

[Author]

Replies