[Eric Fortenberry]

I believe the problem is that exec expects a list of arguments, not a single string:

Incorrect Example: exec “ls -ltr”

Correct Example: exec ls -ltr

[Eric Fortenberry]

It may be worth trying to use an “error database” or “error count” Alert action to trigger your thread to stop on error.  I don’t have much experience doing this, but it seems like it would be possible.

[Eric Fortenberry]

Kevin Scantlan wrote:

Where did you find the documentation about hcialertnotify?

[Eric Fortenberry]

I’ve never used this command or seen it used, but it sounds like it may be related to what you’re trying to accomplish:

Quote:

hcialertnotify

The Global Monitor Alert Notify feature requires command-line support to trigger GM to pop-up the alert notification.

hcialertnotify [-M ] [-f ] [-S ]

Where:

[Eric Fortenberry]

Under the “Configuration > Network Configurator > Process Configuration” topic in the Cloverleaf help files, there is a pretty good description of translation throttling.  It should apply the throttling logic to any routes, not just those using Xlates.

Here’s an excerpt from the documentation:

Quote:

Translation Throttling

Select the checkbox and specify the Minimum,  Maximum, or Percent values. These control how many messages the translation thread processes each time it runs. Under normal circumstances, the translation thread processes all of the messages on its queue. By specifying translation throttling, the number of messages processed is limited. This allows other threads in the engine process to run.

   Minimum  specifies that, if the number of messages on the queue is less than this value, then all of the messages are processed. If the queue has more than this many messages, then the percentage is applied.

   Maximum specifies the absolute maximum number of messages to process. If the Minimum is exceeded, then the percentage is applied. If the resulting number of messages is greater than this maximum, then only the maximum number of messages is processed.

   Percent  specifies the percentage of messages to process if the queue has more than the minimum number of messages.

   Clear the checkbox for the translation thread to process all of the messages in the queue.

Thanks,

Eric

[Eric Fortenberry]

I work with Christopher, and today we failed over our test system using the crontab syncronization scripts mentioned above.  Everything appeared to work great.  The only complaint that I have is that on our system (AIX 6.1), when we load crontab from a file, we lose all the blank lines that help separate and format our different cron jobs.

One change that I have since made to this process is to have the inactive crontab entry make a copy before loading the active crontab.  This should provide us with some information about the state of the crontabs whenever failover occurs.

So, with all that being said, here is the inactive crontab that we now have:

Code:

# This is the inactive version of a crontab that is loaded on
# the inactive node of the Cloverleaf cluster.
#    DO NOT DELETE THIS CRON ENTRY OR FILE!!!!!!

# If the active crontab is available (and thus this node is active), load the active crontab.
* * * * * test -f /clovermisc/cronsync/crontab.active && cp -p /clovermisc/cronsync/crontab.active /clovermisc/cronsync/crontab.loaded.$(date “+%Y%m%d%H%M%S”) && crontab /clovermisc/cronsync/crontab.active

And here is the important pieces of the active crontab:

Code:

#########################################
# Crontab syncing b/w cluster nodes
#########################################
# Load the inactive crontab if the active crontab can’t be found
* * * * * test -f /clovermisc/cronsync/crontab.active || crontab ~/crontab.inactive

# Dump the active crontab in case of change
* * * * * test -d /clovermisc/cronsync && crontab -l > /clovermisc/cronsync/crontab.active

As you see, we dump the currently active crontab.  This eliminates the need for any “unusual” steps to update the crontab.  We can just run “crontab -e” to edit; then on failover, the changes are “just there”.

Thanks,

Eric

[Eric Fortenberry]

Thanks for setting me straight.  I thought that I had written to the process.err log in the past using that technique, but looking into it deeper, I think that I was using the “error” command to write to the process.err file.

Code:

error “This is an ERROR message.”

Unfortunately, I’m betting that this wasn’t exactly what Abe was looking for.

Just when you think you understand…  😉

[Eric Fortenberry]

By writing to stderr, the output should go the error log.

For example:

Code:

puts stderr “This should go to the error log.”

[Eric Fortenberry]

I think the only problem (for your situation) with Keith’s solution is that it is not anchored to the beginning and end of the line (by using “^” and “$” respectively).  Just for kicks, here is my try at a solution:

Code:

if {[regexp — {^[AV]?d{6}$} [lindex $xlateInVals 0] {}]} {
       # do something
}

Thanks,

Eric

[Eric Fortenberry]

I have found that you can access most of the stats using either hcimsiutil from the command line, or you can use the msi commands from a TCL shell.

Check out this TCL script: https://gist.github.com/3718595

This script will print out the “Error Msg” for each thread in your current site.

Thanks,

Eric

[Eric Fortenberry]

Here are the steps to repeat the problem:

1. Add a CONCAT action to an Xlate.

2. Set the separator to a single backslash ().

3. Save.

4. Reload the Xlate.

After reloading the Xlate, you will probably see the separator of the CONCAT action set to double backslashes (\).

The tricky part is that the problem doesn’t show up until you reload/reopen the Xlate.  The IDE appears to be saving the separater as a TCL-escaped string, but when the IDE reads the Xlate file, it appears to be reading the value literally.

Thanks,

Eric

[Eric Fortenberry]

We just recently experienced the same problem with putting backslashes in the CONCAT Separator field.  We are running 5.8 on AIX.

What’s the protocol for submitting bugs that are found?

Thanks,

Eric

[Eric Fortenberry]

We recently just ran into the same issue.  We are running 5.8 on AIX.

Since I found this post first when searching for the issue, I thought that I’d post a link to the post that I believe that you were referencing.

https://usspvlclovertch2.infor.com/viewtopic.php?t=781

Thanks,

Eric

[Eric Fortenberry]

This could also be done with Regular Expressions.

This example would remove the first “X” and all of the characters to the end of the string.

 

Code:

set xlateOutVals [list [regsub {X.*$} [lindex $xlateInVals 0] “”]]

This example would remove the last “X” and all of the characters to the end of the string.

 

Code:

set xlateOutVals [list [regsub {X[^X]*$} [lindex $xlateInVals 0] “”]]

My guess is that you will only have one “X” in your values that you are processing, thus either of the above examples should work.

Thanks,

Eric

[Eric Fortenberry]

I threw a TPS proc together for this problem.  Let me know if it helps.

http://gist.github.com/2933489

Thanks,

Eric

[Author]

Replies