TCL Alert configuration

[Brian Lubkeman]

I am having trouble getting a tcl alert properly configured and compiled.  I am using Cloverleaf 6.0.2.

The tcl proc I’ve written for my experiment is the tclalert template stripped down to bare bones.  It does not use any arguments.

Code:

proc alert_test { args } {
   set retval {}
   lappend retval “VALUE 0”
   lappend retval “MESSAGE {Tcl alert ‘alert_test’ has fired.}”
   return $retval
}

I created a tcl alert with the above proc as the source with no arguments.  It looks like this in default.alrt.

Code:

# Alert config: default.alrt
#
prologue
   who:        blubkeman
   date:       January 15, 2016 1:39:51 PM CST
   type:       alrt
   version:    3.0
end_prologue
#
{ALERT
   { NAME Alert_1 }
   { VALUE tcl }
   { SOURCE {
       { TCL alert_test }
   } }
   { WITH -1 }
   { COMP {== 0} }
   { FOR once }
   { WINDOW */*/*/* }
   { ACTION {
       { notify {} }
   } }
}

After saving the default.alrt file, I reviewed hcimonitord.log and found an error stating, ‘Tcl Alert Script Error: invalid command name “alert_test”‘.

I next tried putting an argument in the source of the alert just to see if that helped.  It did get me past the invalid command name.  Apparently, a tcl alert requires the presence of an argument even if the procedure called doesn’t use it.  Does that sound right?

My default.alrt now looks like this.

Code:

# Alert config: default.alrt
#
prologue
   who:        blubkeman
   date:       January 15, 2016 1:46:41 PM CST
   type:       alrt
   version:    3.0
end_prologue
#
{ALERT
   { NAME Alert_1 }
   { VALUE tcl }
   { SOURCE {
       { TCL {alert_test {NONE empty}} }
   } }
   { WITH -1 }
   { COMP {== 0} }
   { FOR once }
   { WINDOW */*/*/* }
   { ACTION {
       { notify {} }
   } }
}

After saving the default.alrt file, I reviewed hcimonitord.log again and found an error stating, ‘Tcl Alert Script Error: missing close-brace’.

Between the tcl proc code and the default.alrt file, I cannot find a single missing close-brace.

Can anybody point out what I’m missing?

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

Topic

[David Barr]

The first error (invalid command name “alert_test”) could have been that the name of your proc didn’t match what was in the Alert configurator, or your alert hadn’t been added to the tclIndex. I think the Cloverleaf TCL editor should do that for your automatically, or you can run mktclindex from the command line. In any case, it looks like that error went away and you’re on to another problem.

I’m not sure about the “missing close-brace” error. The braces in the config file that you posted all seem to match. Are you using the script editor with the Alert configurator or are you editing the default.alrt file with a text editor? I recommend using the configurator.

[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

[Charlie Bursell]

When you used the script editor did you specify it was an alert proc?  The alert engine looks at the proc header for TPS type

[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

[Peter Heggie]

In version 5.8.4, and possibly others, the Alert function failed to process an alert if the text ‘Alert’ was part of the name. Not sure if lowercase ‘alert’ has the same issue. Can you try renaming the alert to something else?

Peter Heggie

[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]

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

[Ken Smith]

I’d like to see resolution to this thread because I am seeing the same problem here. I basically did all the same things that Brian did and I’m getting the “invalid command name” error. I’m using the same default tcl code provided through the designer with a couple minor tweaks to the proc name, very basic, etc. and can’t get it to fire.

Additionally, it would be nice to know what exactly the Comparing: value is related to. I’ve tried 0 — I think that covers all bases — but the thing never fires. Of course, an invalid command name “my_test” could be preventing it, but it’s hard to say what is going on.

[Brent Fenderson]

Ken, Have you tried setting your retval to 1 to see if it fires? I have a script that is monitoring a print queue that might help.

{ALERT

   { NAME {PLUE FOD has print jobs queueing} }

   { VALUE tcl }

   { SOURCE {

       { TCL {alrt_plue_printer plueprod} }

       { TIME {count 12} }

   } }

   { WITH -1 }

   { COMP {== 1} }

   { FOR {nmin 5} }

   { REPEATING {

       { MAX 30 }

       { TIME {nmin 5} }

   } }

   { WINDOW */*/*/* }

   { ACTION {

       { notify {} }

       { email {

           { FROM cloverleaf@infor.com }

           { TO staff@myfacility.com }

           { SUBJ {cloverleaf alert – picis_rx_file_out has 50+ messages queued} }

           { MSG {the FOD print queue has print jobs queued for more than 5 minutes.  Check prodsiteone – This affects Plue Prescrioption Printing.  

} }

       } }

   } }

}

[Ken Smith]

Hey, Bret!

Thanks for your feedback. I see where I was going wrong – I didn’t have the keylist variable set up properly – it’s the VALUE that triggers the message. Man, I’ve been working on getting this to work for quite a few hours – Thanks!

[Ken Smith]

Incidentally – I *do* have to restart the monitor daemon after making changes to the tcl code.

[Brian Craig]

Hey Ken,

I am having the same issue with this I think that you are. What did you set your keylist variable to?

Thanks,

[Ken Smith]

Send me an email and I’ll send you all I found out about this with screenshots and sample email message.

I kind of lost interest in this because the alerts seem to be inconsistent and we were diverted to more important stuff for the time being. There is an email link in my reply.

[John Douet]

Ken Smith wrote:

Incidentally – I *do* have to restart the monitor daemon after making changes to the tcl code.

This was the last piece of the puzzle for me.  Thanks!  I followed all of the tips given by everyone else here, from choosing tclalert as the proc type to making certain that I was returning values properly, but nothing worked… until I restarted the monitor.  At that point, all three versions of the alert I had built started firing off e-mail to me.  Many thanks, again, for your contribution (though I admit to feeling silly for not having restarted it on my own 🙂 ).

[Author]

Replies