Passing arguments from alert configurator to tcl proc

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

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.

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.

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.

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.

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

Hope this helps,

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.

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.

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.

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:

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.

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

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.

Thanks that makes sense.

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

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

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