Environment Variables

The Environment Variable Concept

The ISO/ANSI C standard requires that a C library include the getenv function, which retrieves the value of a named environment variable. Both the name and value are character strings. The ISO/ANSI C standard does not describe the meaning of environment variables, how they might be set, or even whether it is possible to define them. However, the getenv function should be similar to the getenv function under the UNIX environment, and if the host operating system has a facility similar to UNIX environment variables, getenv should provide a means of accessing that facility.

These properties are fundamental to the behavior of UNIX environment variables:

Environment variables can be set and tested by shell commands. For example,
```
export HOME=/u/george
```
A program can modify its own environment by adding or replacing variables; however, these changes are local to the program.
When one program calls another (for example, using the system function), the calling program's environment variables are passed to the called program. The communication is one way; that is, the caller passes the environment to the called program, but any changes the called program makes to its environment are not available to the caller.
Special forms of the exec function enable a program to pass control to another program with a specially built environment.
Because all running programs have a shell as an ancestor, the environment maintained by the shell is inherited by all of a session's environments, subject to modification by specific programs.

Secondary properties of UNIX environment variables include

Both environment variable names and environment variable values are case sensitive and have no practical length limits.
The shell only permits environment variable names containing alphanumeric characters and underscores. (However, C programs can have defined variables not described by this rule.) By convention, environment variables meaningful to the system are entirely in uppercase, leaving lowercase names for individual applications.
Each program has an external variable, environ , which addresses the list of environment variables. Many older programs access environ for environmental information rather than calling getenv .
The only portable way of modifying the environment is by using environ . Some versions of the UNIX environment implement functions like putenv to modify the environment, but these functions are not portable.

The most difficult aspect of implementing environment variables under the OS/390 and CMS operating systems is that native methods for invoking other programs (ATTACH, CMSCALL) do not provide for a list of variables. For this reason, the SAS/C environment variable implementations provide somewhat different semantics in which variables are shared by all programs in a session, regardless of how the programs are invoked. The implementation was modeled after CMS global variables (also called GLOBALV variables) so that C environment variables could be used as a way of accessing and modifying these variables under CMS. This implementation is adequate for porting many UNIX programs that use environment variables, in particular, for all programs that do not modify their own environment. SAS/C software implements environment variables similar to GLOBALV under CMS, TSO, and CICS. Also, for programs running under the UNIX System Services (USS) shell, the environment variable implementation complies with POSIX.1 and traditional UNIX usage.

CMS Global Variables

CMS global variables are similar to C environment variables but have many differences in the details. Some of the differences are

Global variables can be manipulated from the CMS command line using the GLOBALV command.
Global variables are shared between all programs in a session. Changes made by one program are visible to all other programs.
There are several forms of global variables: storage, session, and lasting. Storage variables retain their values only until the next IPL command of CMS; session variables last until the end of a session; lasting variables keep their values across CMS sessions.
Global variables are initialized from files with known names and formats. By editing the files, you can change the initial values used for global variables the next time you invoke CMS.
Global variables are organized into groups of related variables with a default group named UNNAMED.
Environment variable names are translated to uppercase letters automatically. Both names and values are limited to 255 characters.
CMS does not provide an interface for a program to determine the names of all defined global variables.

SAS/C Environment Variables

SAS/C combines elements of UNIX environment variables and CMS global variables in its own environment variable implementation. The interface has been made as portable as is reasonable, but there is still a large amount of system dependency in this implementation. The most important extensions are environment variable scopes and environment variable groups.

Environment Variable Scopes

SAS/C defines three scopes of environment variables: program, external, and permanent.

Program-scope environment variables

Program-scope environment variables are set in one of two ways. First, they may be specified on the program's command line as described in Chapter 8, "Run-Time Argument Processing," in the SAS/C Compiler and Library User's Guide. Or, for programs invoked by the USS exec system call, they may be passed by the caller of exec .

There are no limits on the size of program scope variable names or values. The names are case insensitive; that is, home , Home , and HOME are considered to identify the same variable. (See USS Considerations for an exception.)

External-Scope Environment Variables

correspond to CMS storage GLOBALV variables. They can be set outside of a program using a system command such as GLOBALV for CMS or PUTENV for TSO. Any changes made by a program are visible to other programs, but all such changes are lost at the end of a session. External-scope environment variables are case insensitive and may have length limitations imposed by the host system.

Permanent-Scope Environment Variables

correspond to CMS lasting GLOBALV variables. Their behavior is the same as external-scope variables except that changes to these variables persist to future sessions.

SAS/C implements program-scope environment variables in all environments. It implements external- and permanent-scope environment variables under TSO, CMS, and CICS.

When a program calls the getenv function to retrieve the value of an environment variable, the scopes are searched in order. That is, first the program-scope variables are checked, then the external-scope variables, and then the permanent-scope variables. This enables you or the program to override the usual value with a more temporary value for the duration of a program or session.

When a program calls the putenv or setenv function to modify or add an environment variable, the change is made at program scope unless some other scope is explicitly specified. Thus, a portable program that changes its own environment will not affect any other program. Scopes are indicated to putenv by a prefix on the environment variable name followed by a colon, for example, external:TZ . Because colons are not commonly used in UNIX environment variable names, this extension has little effect on portability.

Environment Variable Groups

Another extension in the SAS/C environment variable implementation supports group names for external- and permanent-scope variables. If an external- or permanent-scope environment variable name contains a period, the portion of the name before the period is considered to be the group name. For example, the variable name LC370.MACLIBS defines the variable MACLIBS in the group LC370 . An environment variable without a group name is considered to have a default group name of CENV .

CMS group names are limited to eight characters. For this reason, in certain cases, environment variable names containing periods may behave differently in different scopes. For example, the two environment variables TOOLONGFORME.NAME and TOOLONGFORANYONE.NAME refer to the same variable for an external scope but different variables for a program scope. This should not be a problem in normal usage.

Because environment variables in traditional UNIX usage do not normally contain periods, this extension does not ordinarily cause portability problems.

Chapter Contents
Previous
Next
Top of Page