[Brian Lubkeman]

I am still having trouble getting this TCL alert built correctly.  I am back to encountering an error for ‘invalid command name’.  I understand this normally means there’s an issue in the procedure’s code usually involving mismatched braces or brackets.  It could also mean that the procedure did not make it into the tclIndex.

With my procedure, I do see it in the tclIndex, and it executes successfully using hcitcl.  If these two possibilities are eliminated what else is there that could cause this ‘invalid command name’ error?

Brian Lubkeman
Technical Analyst III – Integrations
McFarland Clinic, Ames, Iowa

[Brian Lubkeman]

I have not personally tried using temporary variables in an IF statement, so I cannot claim that to the be issue.  However, you may want to try this instead.

Code:

1(0).1(0).1(%g1).OBX(0).#1(0).[0] eq =3

Brian Lubkeman
Technical Analyst III – Integrations
McFarland Clinic, Ames, Iowa

[Brian Lubkeman]

I’ve done some more experimentation.  I did change my TCL procedure to not include “alert” in any part of its name.  I then cycled the hcimonitord log and error files and re-built the alert to call that new tcl proc name with a dummy argument to get past the invalid command error.  The alert loaded successfully with no error.

Next, I updated the alert to change the comparator from == to != without cycling the log and error files.  The log showed the missing close-brace error.

Next, I cycled the log and error files.  I then changed the alert name from “Alert_1” to “Alert_2” – just enough of a change to allow it to be saved.  This loaded successfully with no error.

Based on these event, it seems to me there is an issue with TCL alerts being saved if the log and error files are not cycled first.  I see this as an administrative nightmare.  If I have even one TCL alert in among all the other alerts, this issue will require cycling the log and error files before every single change no matter how small.

Can anyone confirm this?  Does anyone see a way to resolve it?

Brian Lubkeman
Technical Analyst III – Integrations
McFarland Clinic, Ames, Iowa

[Brian Lubkeman]

This is the complete content of the script file.

Code:

######################################################################
# Name        alert_test
# Purpose:    description
# UPoC type:  tclalert
# Args:     The arguments that are passed from your Alert Configuration.
#           The number of args here needs to match the number in the Alert Config.
#           Ex. If you have 3 arguments, it might look like this:
#           proc alert_test { foo bar baz } { … }
# Returns:  keyedlist containing the following keys:
#           VALUE     The value that is to be used in the COMP operation (required)
#           MESSAGE   The Alert Message, which is accessible in the alert through %A (optional)
#
proc alert_test { args } {
   set retval {}

   lappend retval “VALUE 0”
   lappend retval “MESSAGE {Tcl alert ‘alert_test’ has fired.}”

   return $retval
}

Brian Lubkeman
Technical Analyst III – Integrations
McFarland Clinic, Ames, Iowa

[Brian Lubkeman]

I wrote the tcl proc using the Script Editor.  In doing so, I used Edit -> Add Proc so that I could get the delivered tclalert template.  Since this is an experiment, I didn’t want to actually write anything myself.  That eliminated possible typos by me creating the error.  All I did was take the template and remove all comment lines.

I built the alert using the Alert Configurator.  When selecting the alert source, I picked my tcl proc from the dropdown list, so I know the proc made it into the tcl index.  That also ensures there was no typo in the tcl proc name when added to the alert source.

I did not edit default.alrt using a text editor.  I put the text of the default.alrt file into this post because I thought it was a more complete means of showing the definition than a series of screen shots.  Plus, doing so also showed all the braces.

Brian Lubkeman
Technical Analyst III – Integrations
McFarland Clinic, Ames, Iowa

[Brian Lubkeman]

Jim,

Thank you for your reply.  I believe the vendor whose interface is creating the message has inverted their segment and message delimiters.  The message contains a newline character at the end of every segment and a carriage return at the end of every message.  If I understand the HL7 standard correctly, it should be the other way around.  Assuming this gets corrected the message should start working.

Brian Lubkeman
Technical Analyst III – Integrations
McFarland Clinic, Ames, Iowa

[Author]

Replies