setsite in tcl

Not sure if this will work for you.

hcisetenv -site

I ran this from a hcitcl prompt.

I banged my head against this one for a while…

The solution I settled on is to reset env variables in the Tcl environment.

Here’s a proc to do that.  It calls Cloverleaf’s hcisetenv (a perl script), then uses the return from that to set environment variables in Tcl.

It’s not the most elegant, but seems to work well enough.

You can also do something like this:

But this won’t do a few other things that the command line “setsite”  command does like setting HciSite, HciSiteDir, auto_path, etc.

David the issue with your approach is that, while it does set local variables in the Tcl shell you’re running, it doesn’t set environment variables in the Tcl shell.

That works fine as long as you only want to use the variable values locally, but if you want to exec a command from Tcl in the scope of a site other than the one your Tcl shell started in, you need to change the env() array variables in your current shell.

Actually my approach does update the env array.

Instead of struggling with changing sites inside TCL, I went to doing it in the K-Shell that wraps around my TCL.

Here is a URL to illustrate that approach

<a href="https://usspvlclovertch2.infor.com/viewtopic.php?t=6876&#8243; class=”bbcode_url”>https://usspvlclovertch2.infor.com/viewtopic.php?t=6876

Russ –

Todd’s question was about setting site from inside Tcl.

I may have missed something, but the post in the link you supplied looks to address only KSH.

You are correct about my URL showing an approach of using KSH instead of TCL to change sites.

I was attempting to illustrate another way to approach looping thru sites that worked for me that was less hassle as opposed to doing it in TCL.

I wasn’t even sure it was possible to loop thru sites in TCL correctly until msiDetach came along, and by then I already had an apporach of using the KSH site change wrapper.

So basically the KSH script changes sites effectively without observed issues or side effects and calls the TCL script(s) that assume the site has already been set when it is called.

If staying with TCL 100% is one of your conditions, then my URL posted appoach will not meet that condition.

David –

I’ll be dipped – so it does…  Looks like I worked too hard at that one.

I didn’t notice the “tcl” flag – didn’t know it existed.

I had not found the option.  It’s not listed in the  usage at the shell level and it’s buried in my CL documentation.

So, Todd.  I’d do it David’s way ;0)

Russ –

You’re absolutely right.  If KSH is your starting point, there’s no pressing need to do it all in Tcl – unless you want to.

My need – and I’m assuming Todd’s as well – is primarily from within Tcl UPOC/TPS code inside of Cloverleaf.  From there, it’s much cleaner if you can stay in Tcl.

Hi Todd.

We are on *ix and generally run one script that loops through the Cloverleaf sites and then calls a second script to perform  the action.

When the second script has completed its work, the envieronment is dropped until the next call.  The second script can also be called from  the command line.

eg

cycleAllLog.sh calling

 cycleLog.sh

cycleAllSmat.sh calling

cycleSmat.sh

purgeAllSite.sh calling

 purgeSite.sh

This will work for the first thread, outputing the stats correctly. However when i try to do the msiAttach on the next site i get the following error:

Has anyone run into this before?

It seems like I’ve run into this and I don’t remember what I did to fix it.

If you want to stay 100% tcl, one possible solution is to loop through all of your sites, call “fork” to spawn a child process. The child process could call msiAttach/msiDetach/exit. The parent process could call “wait” to wait for the child process to finish with each site.

Even though my KSH wrapper for changing sites that calls TCL scripts takes care of my needs, this topic of using all TCL became a splinter in my brain.

I tried all kinds of variations inside a single TCL proc to loop thru sites but always ran into trouble when doing the msiAttach past the first site just like the rest of you indicated.

I asked Steve Fraser and he had the same outcome but did make me aware of a built in cloverleaf TCL proc named ChangeSite that looks promising.

Then I started thinking about a TCL wrapper approach since my KSH wrapper approach works and that showed promise as the following proof of concept examples produced the outcome I was looking for.

Naturally I was looking at a small set of outcomes to determine if success was possible, so swim at your own risk.

Here is my /hcitest/russ/test_changing_sites.tcl standalone wrapper script:

Here is the /hcitest/russ/test_msiTocEntry.tcl standalone TCL script:

I got to wondering if msiDetach was even necessary when using a TCL wrapper approach like this so I commented it out and my test still worked fine with no complaints about aleady being attached.

I find myself wondering If I understand how msiDetach is intended to be used because the next msiAttach after the first msiDetach never worked when inside the same TCL script and it doesn’t appear to be necessary when using a wrapper approach.

Here is the output from running /hcitest/russ/test_changing_sites.tcl scripts

With regards to msiAttach, I consider it prudent to check to see if the $HCISIEDIR/exec/monitorShmemFile exist and if it doesn’t then I don’t run msiAttach.

I don’t know about current versions of cloverleaf but in the past running msiAttach would create $HCISIEDIR/exec/monitorShmemFile after which mysterous problems would surface.

This was an effective workaround since if no $HCISIEDIR/exec/monitorShmemFile exist, then the site most likely is not running.

Here is an example:

Greetings,

Running CIS 6.1.0 on AIX 6 TL9 (HA virtualized).

Russ, our Tcl programs that invoke the msiAttach comannd surround the call with a catch.  For a site we find that you can only call msiAttach once in a TCL instance (running program).  Otherwise you get an error but it is not fatal.  Keeps the return values “clean”.

Sample code:

    if {$mode == “start”} {

         catch {msiAttach}

    } elseif {$mode == “run”} {

       set threadstats [msiGetStatSample $url_thread]

       keylget threadstats OBDATAQD pend_count  ;#get the pending count for the requeue thread

Hope this helps.

Enjoy.

We are on 5.6, so don’t have msiDetach, but do recall attempting to just change sites and then run msiAttach again which just crashed and burned…

So, to loop through all sites for diagnostic/monitoring, I found it necessary to exec a call to hcicmd to get thread/process info.

I then evaluate the returned resultList and glean whatever info I’m looking for.

Using exec was not my preference, but looked to be the only option for what I was trying to do.

I find myself liking Jeff’s approach, too.

I tested it on a site where the monitod wasn’t running and it returns an error code of 2, plus doesn’t start the monitord or create a shared memory file that can cause problems later on like it does with msiAttach.