can OS be accessed from an xlate

I think so, using “exec” function.

Something that would probably use less system resources is to make use of the newer versions’ global variables which should be accessible from an xlate proc.

Depending on what you’re looking for, it may be available in the built-in env() array.

For example:

global env
puts $env(HOSTNAME)

• This reply was modified 1 year, 7 months ago by James Nelson.

set xlateOutVals [info hostname]

My advice would be to set a global variable to indicate whether the system is prod or dev. We use a lookup table ‘system_vars’ for this, same result.

Checking the hostname may work now, but when the servers change (after a migration) you will have a problem.

Was going to add we do something similar that Robert mentioned where we have a master site and within there use a global variable to delclare Test or Prod, see attached screen shot.

If you need to call this from an xlate

Source side: =$$GLOBAL_MSH_11      Output side: 0(0).MSH(0).#11(0).[0]

If you need to call this from a tcl proc

set envrionment TEST
set server [gvgetvar GLOBAL_MSH_11]
if {$server == “P”} {
set envrionment PROD
}

As mentioned above we’ve also used exec and info hostname via tcl

set srvr [string toupper [string range [exec hostname] 6 9]]

set hostName [info hostname]

Since we run AIX we have also used hostname for KSH

myhost=<code>$(hostname)</code>

• This reply was modified 1 year, 7 months ago by Jeff Dawson.

I am a bit confused as to why and make this hard?  The global variable, already provided, HciSite will suffice.  If $::HciSite eq “sitename”.  That is unless you have a lot of test sites.

Hi Charlie,

We have a separate Tst and Prd Cloverleaf cluster where Tst and Prd have the same sites.  (Tst has some extra sites, like ‘dev’). So based on the site name you can’t determine whether it’s Tst or Prd.

I understand Robert but why not give sites meaningful names that would include test in the name?