- This topic has 11 replies, 4 voices, and was last updated 6 years ago by
.
-
Topic
-
-
Replies
-
-
-
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.tblI’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?
-
-
I found something in the old archives… It’s from 2004…:
Date: Thu, 30 Dec 2004 15:35:45 -0600
Author: “Charlie Bursell” <
charlie.bursell@quovadx.com >Subject: RE: Table Lookup in Alerts
Body: This is a multi-part message in MIME format.
=_NextPart_000_0015_01C4EE85.3B8528A0Content-Type: text/plain;
charset=”iso-8859-1″
Content-Transfer-Encoding: 7bit
RE: Table Lookup in AlertsHowever, if Table Lookups are something you need
to do via Tcl from the Alerts, let me know and I’ll provide you a
work-around.
Charlie
Original Message
From:
bounce-clovertech-586@ajax.quovadx.com [mailto:
bounce-clovertech-586@ajax.quovadx.com ]On Behalf OfMark.E.Thompson@HealthPartners.Com Sent: Thursday, December 30, 2004 2:19 PM
To: Technical Issues
Subject: [clovertech] RE: Table Lookup in Alerts
As confirmed by Quovadx Support:
When using a Tcl proc in an alert action type of Tcl, the proc will fail
if it contains a table lookup. The same proc will work if it is called with
an exec action. For example, if I have a proc named alert_test that
contains a table lookup, the action {tcl alert_test} with fail with an
“[aler:aler:ERR /0: hcimonitord] Tcl error: unable to load table
‘mytable.tbl'” error, but the action {exec {hcitcl -c ‘alert_test’}} works
fine. This has been confirmed on 5.3 (no revs) — not sure if it is true on
other versions.
-Mark
-
-
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.
-
-
Anyone have a modification to this tblGet proc from Charlie that supports the original value if checked? It tends to work nicely when used in tcl based alerts and doesn’t require a bounce of the monitor daemon when modifying any of the tables being used.
The only issue I have found is the support of Keep Original Value instead of default. Some instances this would be helpful. Thoughts?
-
Think I got it…
Added to this section:
# Get default value
set dflt [TioGetDefault 1]
set passThru [TioGetPassThrough 1]
# If the value does not exist, Just return default
if {![TioExists 1 $val $side] && $passThru == 1} {
return $val
} else {
return $dflt
}
This appears to do the trick. If there is a better way, I appreciate the guidance/advice.
-
-
This looks to be working…
# Get default value
set dflt [TioGetDefault 1]
set passThru [TioGetPassThrough 1]
# If the value does not exist, Just return default
#if {![TioExists 1 $val $side]} {return $dflt}
if {![TioExists 1 $val $side] && $passThru == 1} {
return $val
} elseif {![TioExists 1 $val $side] && $passThru == 0} {
return $dflt
}
-
- The forum ‘Cloverleaf’ is closed to new topics and replies.
