Passing arguments from alert configurator to tcl proc

[Nicole Goodyear]

Has anyone ever tried to pass the thread name to a tcl proc when using the alert configurator?  Any help with this would be greatly appreciated!

Topic

[Charlie Bursell]

The thread name is not available except in the alert message.  You can pass the alert message with %A and parse the thread name from that.

For example if using a protocol status alert, I do something like:

set thdPat {protocol status of (m.*?M) is}

set thdName “”    ;# Just in case

regexp -nocase — $thdPat $alrtMsg {} thdName

Where alrtMsg is the alert message that was passed to my proc

[Nicole Goodyear]

Thanks Charlie, that’s exactly what I was looking for!  

OK, so now we’ve built our tcl proc but are having difficulties getting it to run through the alert configurator.  Right now, all I would like to do is set up an alert that calls a tcl proc.  This tcl proc is sending out an email.  I have made my tcl proc executable, has all permissions and I have declared the tcl library at the top of the tcl (#!/quovadx/qdx5.5/integrator/bin/hcitcl).

I have checked the hcimonitord error log and am getting the following:

[aler:aler:WARN/0:  hcimonitord:08/22/2008 09:56:40] Alert #0 triggered.

alert: {VALUE status} {SOURCE {ResendClient }} {MODE actual} {WITH -1} {COMP {== up}} {FOR {nsec 30}} {WINDOW {* * * * * *}} {HOST {}} {ACTION {{exec Thread_Opening.tcl}}}

action: Thread_Opening.tcl &

[aler:aler:WARN/0:  hcimonitord:08/22/2008 09:56:40] Completed Cascade Actions

This tells me that it is tirggering the tcl, but I am never getting an email.  I am calling the tcl in the alert action as exec Thread_Opening.tcl.

Can anyone give me any ideas on how to get this alert working please?

Thanks in advance

[Robert Milfajt]

Can you plug in a copy of your TCL?  It may be a simple syntactical type of error.

One suggestion is that within your TCL, you could include debug that you would write to a file and see where things are breaking down.

Robert Milfajt
Northwestern Medicine
Chicago, IL

[Russ Ross]

Nicole:

Here is one of my previous posts that shows how I pass args, including a hardcoded thread name, to a stand alone KSH proc (recycle_thread_alert.ksh) using the Cloverleaf alert utility.

https://usspvlclovertch2.infor.com/viewtopic.php?t=1806&” class=”bbcode_url”>https://usspvlclovertch2.infor.com/viewtopic.php?t=1806&

I expect the same approach would also work for a standalone TCL script.

I recall this question coming up several times on clovertech and doing a search on alerts might also give additional examples for you to look at.

Russ Ross
RussRoss318@gmail.com

[Nicole Goodyear]

Russ, thank you for the link to your post, now that I have a better understanding, your post makes perfect sense!  

I have added my directory to the hci path and I can now call this tcl proc from the command line and it sends me an email, but now when I try to call it in the alert configurator, it is not executing the proc.  After speaking with Charlie, he mentioned that I should call the proc at the end of the proc so that it will actually execute when I call it in the Alert Configurator.  I’ve tried this but I am not getting an email.

I have tried the following alert actions with no success:

{tcl ThreadAlert.tcl} – gives me an invalid command name

{exec ThreadAlert.tcl}

Any thoughts?  Thanks again everyone!

[Robert Milfajt]

Quote:

I have tried the following alert actions with no success:

{tcl ThreadAlert.tcl} – gives me an invalid command name

{exec ThreadAlert.tcl}

Any thoughts?  Thanks again everyone!

What does the first line of ThreadAlert.tcl look like?  If it is not something like the following, the {exec ThreadAlert.tcl} will not work because it does not know what shell to execute the script.

Code:

#!/qvdx/qdx5.5/integrator/bin/hcitcl

If you want to call a tcl proc, {tcl procname}, you need to do a couple of things with ThreadAlert.tcl.  First, you need to have something like the following inside of ThreadAlert.tcl.

Code:

proc procname {
    YOUR TCL CODE HERE
}

Then you need to put this proc in $HCISITEDIR/tclprocs and run the mktclindex command to define the proc.

Hope this helps,

Robert Milfajt
Northwestern Medicine
Chicago, IL

[Nicole Goodyear]

Hi Robert,

The first line of the tcl proc has the shell location

(/quovadx/qdx5.5/integrator/bin/hcitcl)

also, my tcl proc is formatted in the way you described and I have done a mktclindex on it.

Not sure why this is not working in Alert Configurator, but I’m sure it has to be something very easy that I’m missing!

[Russ Ross]

Personally, I prefer to use the directories already defined in the default path by hci so I put my stand-alone scripts in $HCISITEDIR/scripts to avoid being bothered by pathing issues.

You might have to create the directory $HCISITEDIR/scripts manually.

When I do find it necessary to add paths not defined by cloverleaf, I’ve had success by modfying $HCIROOT/bin/hcisetenv to accomplish this across the board.

WARNING: Be safe and make a recoverable backup copy of hcisetenv before making any modifications.

With the advent of the master global site in QDX 5.6, I will no longer have a need to modify hcisetenv to locate global scripts in my master site anymore.

Also, I start all my stand-alone TCL scripts with the following lines so I never have to remediate them when doing future cloverleaf upgrades.

Code:

#!/usr/bin/ksh
# this line to escape the next line from the tcl interpreter
exec hcitcl “$0” “$@”

These lines cause the a stand-alone TCL script to dynamically find the correct version of the hcitcl interpreter like magic even when there are multiple version of cloverleaf running on the same server.

Here is a handy script ( parse_path.ksh ) to visually display the current path one directory per line that I find helpful when looking to see what is in the currnet path.

Code:

#!/usr/bin/ksh

echo $PATH:$FPATH | awk -F: ‘{for (i=1;i<=NF;i++) print $i}'

This script will also display those sneaky FPATH directories that make some things very hard to locate like setroot.

Here is another handy script ( find_path.ksh ) that shows all occurenes of the file(s) of interest so you can see the higharcey of execution when you get confused because the same object is defined in 2 differenct search path directories.

Code:

#!/usr/bin/ksh
#
# Begin Module Header ==============================================================================
#
#——
# Name:
#——
#
# find_path
#
#———
# Purpose:
#———
#
# search all the default paths (echo $PATH) for the specified file
#
#——-
# Notes:
#——-
#
# Example of normal useage:
#
#    find_path parse_hl7
#    find_path “parse*”
#    find_path ‘parse*’
#    find_path parse*
#
#———
# History:
#———
#
# 1999.12.14 Russ Ross
#          – wrote initial version
#
# End of Module Header =============================================================================

pathDirList=`parse_path.ksh`

echo ” ”

for pathDir in $pathDirList; do
  ls -l $pathDir/$1 2>/dev/null
done

echo ” ”

It will even show you where to find that sneaky setroot function by doing

find_path.ksh setroot

I would also recycle the monitor daemon each time I make a change to the search path to feel more comfortable the change gets picked up by the alerts.

From the command line this should do it:

Code:

hcisitectl -k m
hcisitectl  -s m -A “a=-cl ‘default.alrt'”

In my case there is a script that touch $HCISITEDIR/defualt.alrt file once an hour during the day to make sure the alerts are refreshed and persistant but not to persistant.

Russ Ross
RussRoss318@gmail.com

[Gary Atkinson]

Quote:

In my case there is a script that touch $HCISITEDIR/defualt.alrt file once an hour during the day to make sure the alerts are refreshed and persistant but not to persistant.

Ross-

I am curious what you mean by the alerts are refreshed and persistant but not to persistant?  How does the touch command affect the .alrt file?

thx,

Gary

[Russ Ross]

Touching the default.alrt file casues the alert to be reset so to speak.

For example if I have an alert to go off after a thread is down for 10 mintes I will get that alert once when that condition occurs.

However, by touching the default.alrt file once an hour, I will get the alert about the thread being down once an hour until the condition is resolved.

That is what I mean about persistant becuase my alerts will keep going off but not too often because I wait an hour to touch the default.alrt file.

I have found this to be a good comprimise.

Russ Ross
RussRoss318@gmail.com

[Gary Atkinson]

Thanks that makes sense.

[Robert Milfajt]

Quote:

Touching the default.alrt file casues the alert to be reset so to speak.

Does it follow that editing an alert file causes it to reset?

As a follow up, does the simple act of editing the file cause it to be reloaded?  Currently we bounce the monitord to reload the alert file, but I am sure there is an easier way, I just cannot recall what it is.

Thanks,

Bob

Robert Milfajt
Northwestern Medicine
Chicago, IL

[Russ Ross]

You might find many of these discussions took place already in this URL

https://usspvlclovertch2.infor.com/viewtopic.php?t=2264&#038;” class=”bbcode_url”>https://usspvlclovertch2.infor.com/viewtopic.php?t=2264&#038;

Russ Ross
RussRoss318@gmail.com

[Author]

Replies