Environmental Variables

Environmental Variables in Unix and MSDOS

Unix and MSDOS support environmental variables. These are character strings whose values may be set from the command prompt, or from a shell script (in Unix) or batch file (in MSDOS). Each environmental variable has a name. An application may use that name to query the operating system for the value of an environmental variable.

Some environmental variables have standardized uses. The most familiar example is PATH, which specifies a list of directories where the shell is supposed to look for executable files.

Other environmental variables may be customized for a particular application. For example, an environmental variable may specify the name of a file, or the name of a directory, or any kind of run-time option.

In effect, environmental variables are global variables which are initialized by the operating system.

Environmental Variables in MVS

MVS does not support environmental variables. There are two traditional ways to specify run-time options:
  1. Code a PARM clause in the JCL, or

  2. Read a little file of control cards.
These devices tend to be very ad-hoc. As a result, the developer may be reluctant to provide much run-time flexibility, because it's such a nuisance to program. If there are very many run-time options, the various ways to specify them are likely to clutter up the code, the JCL, and the user's life.

Environmental Variables in JOCKEY

The JK015 routines provide something like environmental variables within MVS, using COBOL. They load a WORKING-STORAGE table from a small control card file which defines environmental variables with a standard syntax. With a single CALL statement, any program within the load module may obtain the value of any given environmental variable. Additional environmental variables require no JCL changes.

By calling a separate entry point, the application may add, update, or delete an environmental variable as stored in the table.

Using Environmental Variables

Why would you want to use environmental variables?

First, a program may need to behave differently under some circumstances: different jobs, different data centers, or special occasions.

Second, you may need to adjust something in the light of experience. You may not even be sure whether you want a certain behavior. With environmental variables you can experiment, varying several different things independently, without changing the program.

Third, you can smooth the process of introducing new features. You can install new software with the new features turned off. Try out the new features at a single site, to limit the damage if they don't work right. Or wait for something else to happen (like a new release of a related application) before you turn on the new features.

[home]COBOL Home [globe]Global variables