Environment Control

Setting the environment is critical for correct job execution. Accelerator provides two methods to control the execution environment.

Use a snapshot of the environment used at submission time.
This method is the simplest and is automatically selected if the environment variable VOV_ENV is not defined. The disadvantage of this method is that the snapshot may not be portable across platforms.
Note: This method is not available for Windows.
Use a named environment, which allows the tasker to create the environment on the fly using the VOV Environment Utilities.
This method offers several advantages: strict control on the environment, greater efficiency, less disk space utilization, easier execution across multiple platforms. This method is used if the environment variable VOV_ENV is defined; the value of the variable indicates the name of the environment to use.
Note: This method is required for Windows.

Use Environment Snapshots

An environment snapshot will be created and used under the following conditions:

The environment variable VOV_ENV is not set.
The environment variable VOV_ENV is set to the value "" (the empty string) or the value DEFAULT.
The environment variable VOV_ENV contains the substring SNAPSHOT.

The snapshot is represented by a file, the location of which is controlled by the environment variable NC_SNAPSHOTDIR. This variable can take one of the following symbolic values:

Possible values of nc_snapshotdir
homedir	Use directory ~/.ncsnapshots/$VOVARCH
serverdir	Use directory PROJECTNAME.swd/snapshots/$USER/$VOVARCH
any other value	Use the directory $LOGDIR/snapshots/$USER/$VOVARCH, where LOGDIR is controlled by the variable NC_LOGDIR and has default value ./vnc_logs

The environment snapshot is a file in Bourne-Shell syntax, which contains most of the variables in the current environment. The variables that are excluded from the snapshot include the following: HOST OSREV OSTYPE TERMCAP SHELL PWD. These variables are defined in the file $VOVDIR/tcl/vtcl/vovenvutils.tcl

An environment snapshot may be shared by many jobs.

When using a snapshot, the job is submitted with environment SNAPSHOT(name_of_snapshot_file).

Note: This is a named environment.

To force the creation of an environment snapshot:

Ensure sure the environment variable VOV_ENV is not defined.
Do not use the option -e.

% unsetenv VOV_ENV
% nc run sleep 10
Resources= linux
Env      = SNAPSHOT(vnc_logs/snapshots/joe/linux/env4590.env)
Command  = vw sleep 10
Logfile  = vnc_logs/20020704/180936.7793
JobId    = 00350601
vnc: message: Scheduled jobs: 1       Total estimated time: 0s

Named Environments

The Accelerator Environment Utilities consist of two commands: vel, lists the available environments; ves switches between environments. For more information, refer to Environment Management.

The following example lists the available environments and switch to the environment called BASE.

% vel
vel: message: Environment directories:
1 /release/VOV/latest/sun5/local/environments
1 . tcl BASE            UNIX utilities, X windows, and VOV
1 . tcl D               Define vars: Usage: ves "+D(VAR1=value1,...)"
1 . tcl DEFAULT         Just a name for whatever you already have.
% ves BASE

Select a Named Environment

When submitting a job, to select the environment in which to run the job, use the option -e. Examples are shown below:

% nc run -e BASE sleep 10
...output omitted...
% nc run -e BASE+SPICE sleep 10
...output omitted...
% nc run -e "BASE+D(MYVAR=somevalue)" sleep 10
...output omitted...

Use Snapshot with Named Environment

A combination of an environment snapshot and a name environment can be set up. Try the following example shows using the -e option to set up a combined environment with a SNAPSHOT plus a name environment CALIBRE:
```
% nc run -e SNAPSHOT+CALIBRE sleep 10
...output omitted...
% nc run -e SNAPSHOT+MODULE1+CALIBRE sleep 10
...output omitted...
```

Environment Processing

The following table represents the stages and behavior of the VOV named-environment management subsystem (multienv) in the course of job execution. Named environments are defined in scripts, searched for in the following directories:

$VOV_ENV_DIR
$VOVDIR/local/environments
$VOVDIR/etc/environments

in that order.

Table 1.
Start	Pre	Post
Script <envName>.start.<csh\|sh\|tcl>	Script <envName>.pre.<csh\|sh\|tcl>	Script <envName>.post.<csh\|sh\|tcl>
Processed by: NC: vovtaskerroot > subtasker > vw	Processed by: NC: vovtaskerroot > subtasker > vw	Processed by: NC: vw > subtasker > vovtaskerroot Others: vw > subtasker > vovtasker
Processed when: Prior to job PRE command (if defined) and job start	Processed when: Prior to job PRE command (if defined) and job start	Processed when: After job termination and prior to POST command (if defined)
Available variables: VOV_PROJECT_NAME VOV_JOBID WX: set to the ID of the wxagent job in NC Others: not set All variables inherited from tasker environment	Available variables: VOV_PROJECT_NAME VOV_JOBID WX: First call (vovtasker): set to the ID of the wxagent job in NC Second call (vw): set to the ID of the WX job Others: First call (vovtasker): not set Second call (vw): set All variables set by START All variables inherited from tasker environment	Available variables: VOV_PROJECT_NAME VOV_JOBID WX: First call (vw): set to the ID of the WX job Second call (vovtasker): set to the ID of the wxagent job in NC Others: First call (vw): set Second call (vovtasker): not set All variables set by START and PRE All variables inherited from tasker environment

Note:

Non-root taskers (products other than NC) process each START environment once, the first time it is referenced by a job, then cache the resulting environment variables and their values. Subsequent requests to process the same START environment will result in the cache being used instead of the script being reprocessed. The vovtaskermgr refresh command can be used to purge the cache and cause the START environment to be reprocessed the next time it is encountered.
The PRE and POST environment processing stages are undocumented, so PRE and POST environment scripts normally do not exist. They are processed if they exist though.
Because the PRE and POST commands are executed twice, once with VOV_JOBID defined and once without, steps must be taken in the PRE and POST environment scripts to check for the existing of the variable before using it.
The END stage, which is used to clean the environment from modifications made in the previous stages is not called in the course of job execution. It is used exclusively by the ves CLI command and the vovbuild command.
Job PRE and POST commands are executed by the subtasker, so neither will have access to the VOV_JOBID variable.
NC's container integration has no bearing on the behavior.