msiAttach Revisited

[Max Drown (Infor)]

From what I can tell after searching the forums for “msiAttach”, there is no way to detach from the msi shell. This means that you can not script a loop across sites to display results from msi. Is this still true? Has anyone written a reliable work around for this?

I’ve tried writing a tcl proc that calls a tcl proc, but I still get an error when the site changes. See the code below.

#!/hci/quovadx/qdx5.6/integrator/bin/tcl

set hciRoot /hci/quovadx/qdx5.6/integrator

# List of sites to exclude from the search
set siteExclusions {dev_joe dev_max}

# Get site names from the server.ini
set sites [exec grep environs $hciRoot/server/server.ini]
regsub {environs=} $sites {} sites
set sites [lsort [split $sites ;]]

foreach site $sites {
[code]#!/hci/quovadx/qdx5.6/integrator/bin/tcl

set hciRoot /hci/quovadx/qdx5.6/integrator

# List of sites to exclude from the search
set siteExclusions {dev_joe dev_max}

# Get site names from the server.ini
set sites [exec grep environs $hciRoot/server/server.ini]
regsub {environs=} $sites {} sites
set sites [lsort [split $sites ;]]

foreach site $sites {

-- Max Drown (Infor)

Topic

[John Mercogliano]

Max,

 Look at this link for a procedure I wrote to switch a site from within tcl,

<a href="http://clovertech.infor.com/viewtopic.php?t=2055&highlight=switchsite&#8221; class=”bbcode_url”>http://clovertech.infor.com/viewtopic.php?t=2055&highlight=switchsite

the one thing you are missing is a call to setHciDirs

 Also, no matter what, you will not be able to call checkStatus as a procedure.  You will have to create it as a stand alone executable and call it using exec.  That is the only way to get msiAttach to think it is running in it’s own memory space and reconnect to another site.

Hope this helps

John Mercogliano
Sentara Healthcare
Hampton Roads, VA

[Russ Ross]

I’m not clear about the problem you are describing but I have been looping across sites calling msiAttach for years.

Mostly right now we run a script that loops across all our active sites and calls msiAttach to dynamically generate HTML web pages with the stats returned from msiAttach.

I ended up creating shared memory problems in the beginning until I learned to never call msiAttach for a site unless the shared memory file already existed.

Here is what I ended up doing at the beginning of my TCL script that calls msiAttach that seems to have solved the symptoms of the shared memory problems that were happening.

Code:

    if { [lsearch -exact [ls $HciSiteDir/exec] monitorShmemFile] == -1 } { return }

Here is the entire oth_get_stats.tcl proc to illustrate

Code:

proc oth_get_stats {THREAD} {

    global HciSiteDir
    if { [lsearch -exact [ls $HciSiteDir/exec] monitorShmemFile] == -1 } { return }

    msiAttach

    set pStatus “unknown”
    set obDataQD “0”
    set pLastRead “0”
    set msgsIn “0”
    set pLastWrite “0”
    set msgsOut “0”

    set bytesIn “0”
    set bytesOut “0”
    set ibLatency “0”
    set obLatency “0”
    set totLatency “0”

    set tocEntry [msiTocEntry $THREAD]
    keylget tocEntry INDEX threadIndex
    msiGetStatSample $threadIndex stats
    keylget stats PSTATUS pStatus
    keylget stats OBDATAQD obDataQD
    keylget stats PLASTREAD pLastRead
    keylget stats MSGSIN msgsIn
    keylget stats PLASTWRITE pLastWrite
    keylget stats MSGSOUT msgsOut
    keylget stats BYTESIN bytesIn
    keylget stats BYTESOUT bytesOut
    keylget stats IBLATENCY ibLatency
    keylget stats OBLATENCY obLatency
    keylget stats TOTLATENCY totLatency

    if {$pLastRead == 0} {
        set pLastRead “never”
    } else {
        set pLastRead [clock format $pLastRead -format “%a %b %d %H:%M:%S”]
    }

    if {$pLastWrite == 0} {
        set pLastWrite “never”
    } else {
        set pLastWrite [clock format $pLastWrite -format “%a %b %d %H:%M:%S”]
    }

    set outStats “$pStatus^$obDataQD^$pLastRead^$msgsIn^$pLastWrite^$msgsOut^$bytesIn^$bytesOut^$ibLatency^$obLatency^$totLatency”
    return $outStats
}

In our case, we end up calling the oth_get_stat.tcl proc from a K-shell script and when we went from Cloverleaf 5.2 to Cloverleaf 5.6 we had to modify how we did this.  Here is some snippet of code from a KSH script illustrating our current work around:

Code:

  for thread in $THREADS
  do

      STATS=$(
          hcitcl <<- !
          echo [oth_get_stats $thread]
          exit
          !
      )

      PROTOSTATUS=$(echo $STATS | awk -F "^" '{print $1}')
      QUEUEDEPTH=$(echo $STATS | awk -F "^" '{print $2}')
      LASTREAD=$(echo $STATS | awk -F "^" '{print $3}')
      MSGSIN=$(echo $STATS | awk -F "^" '{print $4}')
      LASTWRITE=$(echo $STATS | awk -F "^" '{print $5}')
      MSGSOUT=$(echo $STATS | awk -F "^" '{print $6}')

      # etc.
done

Russ Ross
RussRoss318@gmail.com

[Jerry Tilsley]

When using msiAttach I always have to use the exec command to launch another script with arguments for the site info.  This way every time I call the script a new shell is used.

[Max Drown (Infor)]

What I did was create a shell script that calls my proc for each site.

Code:

checkStatus site01
checkStatus site02
checkStatus site03

There’s no way that I can tell to loop through the sites inside the checkStatus script because msiAttach returns an error when you try to change the site.

-- Max Drown (Infor)

[Russ Ross]

Here is another example of a script that illustrates looping over sites and calling msiAttach.

This script checks for shared memory problems by showing what threads are in the shared memory region for a given site but aren’t defined in the NetConfig for that site.

If you do things like msiAttach when the shared memory doesn’t exist you will get alot of shared memory issues showing up when you run this script to highlight them and bring them to your attention.

Here is the code for check_shmem.ksh

Code:

#########################################################################
# This script checks to see if the list of threads in shared memory
# matches what is in the NetConfig
#
#———
# History:
#———
#
# 2004.10.17 Russ Ross
#          – modified to call setroot instead of hcisetenv
#          – modified to skip sites that do not have a $HCISITEDIR/exec/monitorShmemFile
#

ROOT=”$HCIROOT”

SITELIST=$(list_sites.ksh)
if [[ $1 != “” ]];then
   SITELIST=$1
fi

for site in $SITELIST; do
   setroot -clear
   setroot $ROOT $site

   if [[ -a $HCISITEDIR/exec/monitorShmemFile ]]; then
      ### echo “$(hcitcl -c “echo [oth_check_shmem]”)”
      echo “$(
          hcitcl <<- !
          echo [oth_check_shmem]
          exit
          !
      )"
      echo "Site: ”
   fi
done

Here is the TCL proc ( oth_check_shmem.tcl ) that gets called by the site loop above and does msiAttach:

Code:

proc oth_check_shmem {} {

   global HciSiteDir
   if { [lsearch -exact [ls $HciSiteDir/exec] monitorShmemFile] == -1 } { return }

   msiAttach
   set msiList [msiTocEntry]

   netcfgLoad
   set netList [netcfgGetConnList]

   lassign [intersect3 $msiList $netList] extraThreads goodThreads x

   return $extraThreads
}

After looking at your code I realize I should probably be doing a catch around the msiAttach but never had a problem I know of since I added the check for the shared memory file

$HCISITEDIR/exec/monitorShmemFile

I was able to find one shared memory descrepancy to illustrate the output of running the script.  In this example the p_lis_mock site has a shared memory issue indicating somone deviated from our standards and didn’t follow the checklist for modifying a cloverleaf site.

Site:

Site:

Site:

Site:

Site:

Site:

Site:

Site:

Site:

Site:

ob_atc_ors

Site:

Site:

Site:

Site:

Site:

Site:

Site:

Site:

Site:

Site:

Site:

Site:

Site:

Site:

Site:

Site:

Site:

Site:

Site:

Site:

Site:

Site:

Site:

Site:

Site:

Site:

Site:

Site:

Site:

Site:

Site:

Site:

If you’ve never paid much attention to creating standard procedures to follow that take shared memory issues into consideration you might be surprised to find out just how many shared memory issues show up the first time you run this script.

Even though we are aware of some of the pitfalls they still end up surfacing but we have been able to keep them to a minimum as we become more aware and this script has been helpful in making us more aware.

Russ Ross
RussRoss318@gmail.com

[Author]

Replies