tbllookup within Alert

Hi Michael,

The result of the command is:

221418 -rw-r

---

  1 hci      staff           534 Jun 12 13:22 /quovadx/qdx5.4/integrator/clotest1/Tables/alertTrigger_emails.tbl

I’m not sure how much we “own” the entire alertTrigger.tcl proc, but the section covering the customization we asked for is:

       #build final email list

set final_email_list “”

       foreach email $emails {

   if {[string first “@” $email] >= 0} {

#found “@” sign, this is an email address

lappend final_email_list $email

   } else {

#do table lookup and append each additional email address

set table_emails [tbllookup /quovadx/qdx5.4/integrator/clotest1/Tables/alertTrigger_emails.tbl $email]

foreach new_email [split $table_emails] {

   lappend final_email_list $new_email

}

   }

}

The variable $emails is one of the parameters passed into the proc when it is called.  In this instance it contains 2 items, my email address and a lookup string “cbordList”.  Because the latter doesn’t contain the “@” sign, it is supposed to be used as the value for the table lookup.  From the hcitcl prompt, a lookup to the table with this string returns the 2 additional email addresses I expect.  I had inserted an echo statement after the else in the above and confirmed that the variable $email is getting set to “cbordList” prior to the lookup.  I’ve tried the path both with and without backslash escaping the forward slashes, and the original code didn’t have an absolute or relative path, just the table name.

Your request for the command caused me to pay attention to the permissions on the table file, and I did notice that they were not the same for that table as the others in the directory.  I used chmod to make it match the others so that the output from your command is now:

221418 -rw-rw-r–   1 hci      staff           534 Jun 12 13:22 /quovadx/qdx5.4/integrator/clotest1/Tables/alertTrigger_emails.tbl

Then I killed and started the monitor daemon, recreated the conditions that cause the alert to trigger, but I still see the same “unable to load table” error in the log.  Is boucing the monitor daemon enough, or do I need to stop and start the entire engine process in order for it to be able to find the table?

Wow, thanks for all the responses.  It had looked like I maybe needed Charlie’s workaround (whatever that is), but I tried out all of your suggestions.

Reggie, I modified the permissions you recommended, but no go.  And I had been thinking along the same lines as you about it being a problem with environment settings between me running both the lookup and the entire alertTrigger proc successfully from hcitcl, and the Monitor Daemon not being able to.  So I had inserted the following lines at the start of the proc:

#

global env

echo rootdir: $env(HCIROOT)

eval [exec $env(HCIROOT)/sbin/hcisetenv -root tcl $env(HCIROOT) clotest1]

setHciDirs

#

It didn’t seem to cause any new errors, but it didn’t help either.

Michael, I removed the “.tbl” extension from the table name being referenced in the proc, and tried it with and without the path, but no change in the error when called by the alert.

Finally, I thought I would have to hear from Charlie what his workaround was, but the bottom of the original archive email posting from Mark seemed to be saying that a tcl proc with a tbllookup would work from an alert if the “alert action” defined was “exec” rather than “tcl”.  My first attempts at this made the error disappear from the site daemons log, but I didn’t get any emails produced either.  The “exec” action seems to automatically add an ampersand “&” at the end of the action, thus making it a background process.  As such, the echo statements I’d inserted in the proc were no longer displaying in the log, so I couldn’t tell how much of the proc was actually being run anymore.  After much trial and error, it eventually sunk in that I had to surround the entire string (proc name + 7 parameters) with the single quotes after the “hcitcl -c”.  When I define the action for the alert as the following, it now works:

{exec {hcitcl -c ‘alertTrigger “grege@mmc.org cbordList” “WARNING – to_cbord exceeded queue count” “The to_cbord connection has exceeded queue maximum.” “gemini.mmc.org” “mmc.org” “” “”‘}

I don’t know if this was in fact Charlie’s workaround or if he had something else, but my thanks go out especially to Michael for remembering and digging up that old posting from the archive.  I was getting nowhere with this, and while there’s about a day-and-a-half of my life I’ll never get back due to this particular undocumented monitor daemon quirk, at least it didn’t end up in me committing seppuku.

Charlie Bursell found and sent me a substitute proc (tblGet) for the tbllookup function that will work within a regular “tcl action” from an Alert.