Clovertech

Checking Thread Status

› Clovertech Forums › Read Only Archives › Cloverleaf › Cloverleaf › Checking Thread Status

  • Creator
    Topic
  • September 25, 2008 at 8:56 am #50310
    David Harrison
    Participant

      How can I check the status of a thread in a tcl proc?

      What I want to do is: on an inbound thread, check the status of the outbound and create an HL7 ack message with an appropriate error text if the thread is not connected.

      Thanks,

      Dave

    • Creator
      Topic
    Viewing 14 reply threads
    • Author
      Replies
      • September 25, 2008 at 12:53 pm #65582
        James Cobane
        Participant

          Dave,

          Take a look at the msi extensions within Cloverleaf; these tcl extensions provide the facility to take a look at the thread stats (the same info that you see when you click the ‘Status’ button from the Control Panel in NetMonitor.

          With that said, I’m not clear on your ultimate goal – if the outbound thread can’t connect to the external system, the engine will queue the transaction until it can re-connect.  From the engine standpoint, the message is not yet ‘sent’, so it wiould not be expecting a reply.  If you want to react in some fashion if you have not received a reply within some timeout period, then you should look at putting a proc employed in the ‘Reply Gen’ context of the thread.

          Hope this helps.

          Jim Cobane

          Henry Ford Health

        • September 25, 2008 at 1:23 pm #65583
          David Harrison
          Participant

            Jim,

            Thanks for the information.

            The interface I working on is between a maternity system and PAS. The new baby registration takes place on the maternity system which triggers an ADT^A04. Cloverleaf translates this and sends it to PAS which responds with a message to indicate success, or an error of some kind. This message is translated into an ACK message containing the appropriate error text and Cloverleaf sends it back as a reply.

            The maternity vendor is expecting an acknowledgment so if the outbound thread is not connected for any reason I want to be able to inform the system that the link is down. When the link is restored, the queued messages will be sent to PAS but ACKS will not be sent back to maternity.

            I hope this makes sense. Obviously if there are other ways of achieving this then I would welcome suggestions.

            Thanks,

            Dave

          • September 25, 2008 at 2:47 pm #65584
            Jim Kosloskey
            Participant

              David,

              If, in the future, the messages from the Maternity system were to be sent to additional systems (other than the PAS), which system’s acknowledgment would the Maternity System want before sending another message?

              For example, let’s say the Maternity system’s mssages need to go to PAS and LAB. Both systems will provide an acknowledgment. Which one do you send back to the Maternity system, or do you send both? If you only send one, what if the second one has an error? f you send both then the Maternity system needs to be able to handle multiple returned acknowledgments for one message sent – I don’ know of many application systems that can do that.

              In my opinion, the end-to-end ackowledgment method you are descibing is not workable.

              email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

            • September 26, 2008 at 8:07 am #65585
              David Harrison
              Participant

                Jim,

                I agree with your logic in the case you presented

              • November 12, 2008 at 3:31 pm #65586
                David Harrison
                Participant

                  In the light of the advice received I decided not to proceed with this. However, I now have a different use case.

                  I am implementing an interface whereby a vendor connects to a Cloverleaf thread, sends a QRY^A19 and waits 10 seconds whilst Cloverleaf processes the query, sends it to our PAS  and processes the result back to the vendor system as an ADR^A19. The vendor system then disconnects from Cloverleaf.

                  This works ok but if the connection to PAS is down, the query is queued until such time as the PAS interface is restored, after which the query is processed and the result queued awaiting another connection by the vendor system. In the meantime the vendor system has timed out and aborted the query. The next time the vendor system connects with a new query, it gets the result from the previously aborted query.

                  I

                • November 13, 2008 at 5:25 pm #65587
                  Chris Williams
                  Participant

                    Dave,

                    If you’re just wanting to get the status of a given thread, it’s fairly simple. There is a keyed list in the msi for each thread with the following items:

                    ALIVE LASTEXTRACT LASTUPDATE START STOP PSTATUS PLASTREAD PLASTWRITE PLASTERROR PLASTERRTEXT XLATECNT FORWARDCNT ERRORCNT MSGSIN MSGSOUT BYTESIN BYTESOUT IBLATENCY OBLATENCY TOTLATENCY IBPRESMSQD IBPOSTSMSQD OBPRESMSQD OBDATAQD OBREPLYQD INTERTHREAD

                    For more info on msi go to hcitcl and enter “help msi”

                    Code:

                    # do this only once in your proc before making any msi calls
                       msiAttach

                    # get list of thread names currently in msi
                    # there may be more than you’ve defined in NetConfig

                       set threads [msiTocEntry]

                    # get keyed list for the specific thread into $klist

                       set klist {}
                       msiGetStatSample $threadName klist
                       
                    # get thread status into $stat

                       set stat {}    
                       keylget klist PSTATUS stat

                  • November 13, 2008 at 6:51 pm #65588
                    David Harrison
                    Participant

                      Thanks Chris,

                      In Cloverleaf 5.6 I found a tcl command called CheckThreadStatus which, when given the argument of a thread name will return the status, which is exactly what I was looking for.

                      I made the mistake of creating a tcl proc called CheckThreadStatus which led me up the garden path for a while as it gave me very confusing error messages.

                      If anyone can tell me how to remove a tcl proc I would be grateful!

                      Thanks,

                      Dave

                    • November 13, 2008 at 7:59 pm #65589
                      Chris Williams
                      Participant

                        If you want to remove the one you wrote, just open it in the script editor in Cloverleaf, delete all the lines, then save the file. You should see the proc drop off the list of Tcl Scripts.

                      • November 17, 2008 at 2:44 pm #65590
                        Max Drown (Infor)
                        Keymaster

                          David Harrison wrote:

                          Thanks Chris,

                          In Cloverleaf 5.6 I found a tcl command called CheckThreadStatus which, when given the argument of a thread name will return the status, which is exactly what I was looking for.

                          I made the mistake of creating a tcl proc called CheckThreadStatus which led me up the garden path for a while as it gave me very confusing error messages.

                          If anyone can tell me how to remove a tcl proc I would be grateful!

                          Thanks,

                          Dave

                          I don’t see that script in my installation of 5.6. Can you paste the script here? Also, where is that script located on your box?

                          -- Max Drown (Infor)

                        • November 17, 2008 at 3:10 pm #65591
                          David Harrison
                          Participant

                            Max,

                            It’s not a script it’s a command within hcitcl. In my training site I have a thread called MDSCLI_IN:

                            Code:


                            alice % setsite training
                            alice % hcitcl
                            hcitcl>CheckThreadStatus MDSCLI_IN
                            opening
                            hcitcl>

                          • November 17, 2008 at 5:57 pm #65592
                            Max Drown (Infor)
                            Keymaster

                              Thanks.

                              -- Max Drown (Infor)

                            • August 20, 2013 at 8:54 am #65593
                              David Harrison
                              Participant

                                I have another use case for checking the status of a thread within an Xlate. The problem is the msiAttach command takes 15 to 20 seconds to execute and this would seriously impact the interface. I get the same result in Cloverleaf version 5.6 and version 6.0.

                                There is a tcl command CheckThreadStatus but this also takes the same time to execute (it appears to use msiAttach)

                                The only other way I can think of doing it is to use

                              • February 12, 2015 at 3:29 pm #65594
                                Christy Hodges
                                Participant

                                  Where does CheckThreadStatus live? I want to look at the source file.  It works great, but I want to see the source….

                                • February 13, 2015 at 2:27 pm #65595
                                  Jeff Dinsmore
                                  Participant

                                    I’m not sure where the proc itself lives – I did some cursory searching – but we can its content and arguments using Tcl’s “info” command .

                                    On my CL5.6 box, CheckThreadStatus is just calling ::msi::Msi_protocolStatus for the supplied thread.

                                    Below is the result of  “info body CheckThreadStatus”

                                    Code:

                                    return “[::msi::Msi_protocolStatus $thread]”

                                    “info args CheckThreadStatus” shows a single argument

                                    Code:

                                    thread

                                    Jeff Dinsmore
                                    Chesapeake Regional Healthcare

                                  • February 13, 2015 at 4:01 pm #65596
                                    Rob Abbott
                                    Keymaster

                                      David Harrison wrote:

                                      I have another use case for checking the status of a thread within an Xlate. The problem is the msiAttach command takes 15 to 20 seconds to execute and this would seriously impact the interface. I get the same result in Cloverleaf version 5.6 and version 6.0.

                                      Regarding msiAttach, it only needs to be done once when the thread starts.  If you need to use msi* commands I would suggest putting an msiAttach in the start mode of your TPS.  Then it only runs once.

                                      Rob Abbott
                                      Cloverleaf Emeritus

                                  • Author
                                    Replies
                                  Viewing 14 reply threads
                                  • The forum ‘Cloverleaf’ is closed to new topics and replies.