David Dillard

Forum Replies Created

Viewing 14 replies – 1 through 14 (of 14 total)
  • Author
    Replies
  • in reply to: Large XML messages crashing process #120875
    David Dillard
    Participant

      Did you try turning on the Disk-Based Queuing for the process?

      We had a problem with large PDF messages causing memory issues but they seemed to go away after we turned this on.

      The AIX 32-bit limit is a pain

      in reply to: OBR fields to OBX segment #75899
      David Dillard
      Participant

        I would create a translate to iterate over the OBR segments, save the provider information for each OBR then loop over all the OBX segment under the OBR and set the fields using the variables.

        iterate over the OBR segments

             save the provider information into variables

             iterate over the OBX segments for each OBR

                   Set the OBX fields with the variables

        in reply to: ZOM segment #72675
        David Dillard
        Participant

          It is sometimes hard to get those details from Mckessson.

          I have an example from the STAR v0.5 specs, but they have been known to change.

          Hope it helps some.

          ZOM – ORC/OBR extensions
          Seq   Len   Data type   R/O/C   RP/#   Element name
          1      4       SI         R        Set ID
          2     15       CM         O        Alternate placer group number
          2.1   15       ST         O        Alternate placer group number
          2.2                      NS        Application ID
          3      6       ST        NS        External lab location
          4     10       ST        NS        External lab chart number
          5     10       ST        NS        Lab order accession number
          6      2       ID        NS        Lab administration site
          7      2       ID        NS        Lab clinical processing site
          8     75       CM        NS        Reflexor order
          [code]ZOM – ORC/OBR extensions
          Seq   Len   Data type   R/O/C   RP/#   Element name
          1      4       SI         R        Set ID
          2     15       CM         O        Alternate placer group number
          2.1   15       ST         O        Alternate placer group number
          2.2                      NS        Application ID
          3      6       ST        NS        External lab location
          4     10       ST        NS        External lab chart number
          5     10       ST        NS        Lab order accession number
          6      2       ID        NS        Lab administration site
          7      2       ID        NS        Lab clinical processing site
          8     75       CM        NS        Reflexor order

          in reply to: Batch File to check Process state #62116
          David Dillard
          Participant

            I wrote this script to check the processes in our site and send out an e-mail if any of them were dead or down.  A cron job was used to run the script on a regular schedule (every 15 or 30 min depending depending on the time of day)  

            As David pointed out you want to avoid “crying wolf”  — the e-mails either get everyone in a panic or are ignored as false alarms.

            You should be able to modify it for your specific site and e-mail address and adjust the text to read how you like.

            in reply to: Adding <CR> <LF> #60944
            David Dillard
            Participant

              😳

              Sorry for the confusion

              — I did not read your question close enough and my mind took off on it’s own tangent.

              I plead caffeine deficiency

              in reply to: Adding <CR> <LF> #60941
              David Dillard
              Participant

                Hi,

                You can also substitute a CR-LF for every CR in the message using the regsub command

                Code:

                regsub -all “r” $msg “rn” msg

                Like David said, run this on the inbound data before any other formatting or translations take place.

                Here is a sample proc to get you started

                Code:

                proc Add_LF { args } {
                   keylget args MODE mode                  ;# Fetch mode
                   set dispList {}             ;# Nothing to return

                   switch -exact — $mode {
                       start {
                           # Perform special init functions
                       # N.B.: there may or may not be a MSGID key in args
                       }

                       run {
                           # ‘run’ mode always has a MSGID; fetch and process it
                           keylget args MSGID mh
                           set msg [msgget $mh]
                           # substitute all with
                           regsub -all “r” $msg “rn” msg
                           msgset $mh $msg
                           lappend dispList “CONTINUE $mh”
                       }

                       time {
                           # Timer-based processing
                       # N.B.: there may or may not be a MSGID key in args
                       }
                       
                       shutdown {
                       # Doing some clean-up work
                   }
                   }

                   return $dispList
                }

                in reply to: Not sending mail without returns #60921
                David Dillard
                Participant

                  HI,

                  Here is a script I used to e-mail the status of the processes and connections on the engine.  It only sends mail if a process or connection is dead or down.

                  I had this run as an hourly report from a cron job.

                  It should give you a place to start:

                  Code:

                  #!/bin/ksh
                  ###########################################################################################
                  # File:  mailenginestatus.sh
                  #
                  # Author:  David D Dillard
                  #
                  # Description:  This script is used check the process and connection status of the
                  #               QDX engine and send a mail to the notification group with the status
                  #               information
                  #        18jan2005-ddd modified to only send mail if nothing is dead or down
                  #
                  ###########################################################################################
                  site=”live”
                  sitepath=”/quovadx/integrator/liveroot”
                  # If script is not running in the site this will swap into the correct site
                  #   Edit to add whatever scripts you use to swap to your site
                  if [[ $HCISITE != $site ]]; then
                         setroot $sitepath $site >> mailenginestatus.log 2>&1
                         cdsite
                  fi

                  #now that we are in the correct site we can proceed
                  mailto=”enginesupport@company.com”
                  subject=”QDX alert message: Status report for the $site interface engine site”
                  echo “QDX engine status report for the $site site” > mailenginestatus.log
                  date >> mailenginestatus.log
                  echo “nn————————————————————————-” >> mailenginestatus.log
                  echo “The following processes are dead” >> mailenginestatus.log
                  hciprocstatus | grep dead >> mailenginestatus.log
                  echo “nThe following connections are down” >> mailenginestatus.log
                  hciconnstatus | grep down >> mailenginestatus.log
                  echo “nn————————————————————————-” >> mailenginestatus.log
                  echo “Complete hciprocstatus report:” >> mailenginestatus.log
                  hciprocstatus >> mailenginestatus.log
                  echo “nn————————————————————————-” >> mailenginestatus.log
                  echo “Complete hciconnstatus report:” >> mailenginestatus.log
                  hciconnstatus >> mailenginestatus.log

                  tmp=”/tmp/livemailenginestatus.tmp.$RANDOM”            ;# Create random temp file
                  hciprocstatus | grep dead >> $tmp 2>&1
                  hciconnstatus | grep down >> $tmp 2>&1

                  # search the status for any dead or down processes or connections
                  if (grep -c “d” $tmp > /dev/null);
                  then
                      mail -s “$subject” $mailto < mailenginestatus.log
                  fi
                  sleep 2
                  rm mailenginestatus.log
                  rm $tmp

                  in reply to: making changes to a lookup table #59218
                  David Dillard
                  Participant

                    We regularly use purge cache and have not noticed any problems

                    Running: Version 5.3 rev2

                    David

                    in reply to: Xlate GUI problem…. #58739
                    David Dillard
                    Participant

                      I had a problem that sounds similar to what you are experiencing,   I would double click on an item in my xlate but it appeared nothing would happen.

                      In my case the properties window was popping up but it was off my desktop — when I switch to a higher resolution I could see the window on the far right of my screen.

                      I am using version 5.3 so it may vary but here is one way to fix this:

                      Look in the folder C:quovadxqdx5.3integratorclient (or wherever you installed quovadx)

                      There is a file named client.ini

                      Open this up in notepad and look for a section with your username in it similar to this:

                      [user_yourusername_xlate_config]

                      On my computer it looks like this:

                      Code:

                      [user_davdil_xlate_config]
                      property_dlg_pos=48 197
                      property_dlg_size=827 409

                      The property_dlg_pos controls the screen position (with coordinate 0,0 in the upper left of the screen).  The property_dlg_size controls the size of the property dialog window.

                      If the property_dlg_pos coordinates are very large, or even negative the window is probably off the visible screen.

                      Change the values for the property_dlg_pos to move the window to where you can see it.

                      I would backup the client.ini file before making any changes just in case something goes wrong

                      This may not have anything to do with the problem you are seeing but thought I would toss it out there just in case

                      in reply to: Email #58696
                      David Dillard
                      Participant

                        Hi,

                        We send mail out from both alerts and tcl procs using the unix mail command.

                        From an alert, use the exec action.  Echo out a mail message and then pipe it to the mail command:

                        Code:

                        exec {echo “this would be the body of the message” | mail -s “%A”  address1@mail.com,address2@mail.com }

                        The %A variable contains information about the alert that triggered.


                        From a tcl proc you can do the same thing:

                        I usually setup arguments that will let us pass the email arguments into the procedure so we can change them without making changes to the code:

                        Code:

                        set email1 “default@mail.com”
                        keylget args ARGS.EMAIL1 email1
                        exec echo “body message” | mail -s “Subject” $email1

                        More than one email address?

                        Code:

                        exec echo “body message” | mail -s “Subject” “$email1 $email2 $emaill3”

                        in reply to: Batched HL7 messages over tcpip #58412
                        David Dillard
                        Participant

                          I just needed look in the right direction.

                          Once I took a look at the inbound TPS we currently use to ack the client it all became clear.

                          Thanks everyone for the guidance 😀

                          in reply to: End of segment characters changed from x0d to x0a #57855
                          David Dillard
                          Participant

                            Ryan,

                            Thanks for the ideas.   Something must have become ‘hosed’ in the thread’s pending messages, but when you mentioned “resent” messages it gave the idea to save off any messages in the recovery database and then clean them out to start fresh.

                            It did the trick and now things are working fine.

                            Thanks for all your help

                            <>


                            Just for future reference (my own mostly) , I did do some additional troubleshooting

                            The outbound save message really had x0a after each segment.

                            Code:

                            000838f0 7c525553 5045440a 4f42587c 347c5458 |RUSPED.OBX|4|TX
                            00083900 7c363832 3134345e 4e2e474f 4e4f5252 |682144^N.GONORR
                            00083910 484f4541 45204259 20544d41 7c317c4e HOEAE BY TMA|1|N
                            00083920 45474154 4956457c 7c4e6567 61746976 EGATIVE||Negativ
                            00083930 657c7c7c 7c467c7c 7c323030 35313032 e||||F|||2005102
                            00083940 35303834 337c4f4d 4c5e5e5e 30353130 50843|OML^^^0510
                            00083950 32343036 3334367c 52555350 45440a4e 2406346|RUSPED.N
                            00083960 54457c31 7c7c4e65 69737365 72696120 TE|1||Neisseria
                            00083970 676f6e6f 7272686f 65616520 62792054 gonorrhoeae by T
                            00083980 4d412069 73204644 41206170 70726f76 MA is FDA approv
                            00083990 6564206f 6e6c7920 666f7220 656e646f ed only for endo
                            000839a0 63657276 6963616c 0a4e5445 7c327c7c cervical.NTE|2||

                            At one point I thought it might be the the delivery protocol so I made a copy of the thread and routes, keeping everything except setting the copy to deliver the message to a file

                            The message in the copy was correct, so I could eliminate the xlate, tcl procs and other settings in for the route and thread.

                            I knew the protocol was working for other threads without a problem so that led me to look a the actual data.

                            The data format was ok for the thread copy – so that (along with Ryan’s suggestion about resent messages) let me to consider something in the pending message was causing the trouble.

                            in reply to: Auto-bouncing threads #56509
                            David Dillard
                            Participant

                              Hi,

                              We also ran into some problems with a couple of our connecitons where they get ‘clogged up’ and stop sending messages.  The root cause could not be located so a ‘temporary but semi-permanent fix’ was put in place.

                              An alert was setup to watch the thread and to call an external script when triggered.

                              Example:

                              {VALUE opque} {SOURCE Test1} {MODE actual} {WITH -1} {COMP {> 10}} {FOR {nmin 30}} {WINDOW {* * * * * *}} {HOST {}} {ACTION {{exec {bumpThread.sh Testoutbound Test1}}}}

                              The script then uses the hcicmd to stop and start the thread.

                              We created a generic script to allow us to pass in the process and thread names into the script so it can be reused

                              $1 == Process Name

                              $2 == Thread Name

                              #; stop the thread

                              hcicmd -p $1 -c “$2 pstop”

                              #; Set for specific timespan but could be changed

                              #;     to watch and wait for the thread to go down before

                              #;     bringing it back up again

                              sleep 30

                              #; start the thread

                              hcicmd -p $1 -c “$2 pstart”

                              in reply to: Holding messages in engine #56321
                              David Dillard
                              Participant

                                HI,

                                We do an order consolidation process on some of our inbound order messages which sounds similar to what you are after.

                                To do this we use two threads:

                              • One to collect messages from the client and store them in a gdbm database

                              • A second that pulls the messages from the database and consolidates them.  This is on a timed schedule to allow enough time for the client drop off all the orders in a batch.
                              • If you can afford to wait and group messages for a given time frame this will work, however if anything comes in after the cut-off time it will be it’s own message.

                                I am not sure exactly what problems you are running into but I am attaching out code in case our code might help.

                                The attached DOC will give a better explanation of how the tcl code works.

                              Viewing 14 replies – 1 through 14 (of 14 total)