In the DCL, internal-variable management routines, such as the GLpGET/GLpSET of MATH1/SYSLIB are frequently used. (Here, p represents R (floating-point number), I (integer), L (logical variable), or C character variable) An internal-variable management routine keeps the value of the set variable, and returns the value when inquired. It plays a role similar to that of a "bulletin board." Such a routine is useful in
A COMMON block may be used to share information between multiple subroutines,
but its overuse will cripple readability.
Therefore, the use of COMMON blocks is avoided when possible in the DCL.
Reducing the number of subroutine arguments will make the subroutine
less flexible, but needlessly increasing the number of arguments will also
complicate the subroutine. This is where the internal-variable management
routine becomes handy. The term internal variable was originally used
to mean "a variable used inside the package," but it can also be set
and referred to from outside the package. In this sense, it is similar to the
"external variable" for the C language, since they both have the same
scope.
Internal-variable management routines have the nomenclatures xxpGET, xxpSET (xx refers to the first 2 characters of the package), and they keep the values of variables preset by the system (system default). This value can be referred to by using xxpGET, and changed with xxpSET. Most routines in the DCL acquire a parameter by xxpGET when needed, and will use the default value if there are no specifications by the user. When the user specifies a value using xxpSET, this value will be used.
An internal variable can be changed with a runtime option. The runtime option is a specification that enables intervention to the internal variable by communication with external environments during the execution of the program. The specification may be performed by an external file, environment variables, and command-line arguments, but the actual methods available are system dependent. The effect of a runtime option is stronger than the system default, but weaker than the xxpSET specifications.
Since
a xxpSET specifications are stronger than the runtime
option, it cannot be changed during execution. However, xxpSTX
routines, which are weaker than the runtime option, may be used for this purpose.
The xxpSTX routines can be used to set the default
values
(user default) in the program and to change the values during execution.
The methods for setting an internal variable, in descending order of strength of their effects, are
1: xx p SET 2: runtime option 3: xx p STX 4: system default
A runtime option consists of a combination of the "option name"
and "option value," and multiple numbers of options can be specified.
The option name generally takes the form xx:PNAME, which is a
combination of the 'xx', the first two letters of xxpGET/xxpSET
managing the internal variable to impose, and the name of the internal variable 'PNAME'
.
Here is an example for specifying an option through an environment variable. When you want to change the internal variable 'MSGLEV' managed by GLpGET/GLpSET to 1 in a UNIX C shell environment, type
> setenv GL:MSGLEV 1
The name of the environment must be all in uppercase letters.
When specifying the option through command- line arguments, generally add '-' to the option name, and place '=' between the option name and value, and specify in the form of '-xx:PNAME=value' . (Unlike an environment variable, this is not case sensitive.) For example, while executing the program sample, typing
> sample -gl:msglev=1
will get the same result as the above example for the environment variable.
Do not put spaces before or after the '=' symbol.
When specifying the option through an external file, create a file with the option name and value, with the name .dclrc, for example, in the current directory.
gl:msglev 1 gl:lmiss .true.
The option name should be written from the first column, and the option
values must be separated by more than one space (no tabs are allowed). The rules
for searching the file to read are listed in Chapter 2.
When the same option is specified through an environment variable, a command line argument, and an external file, the order of superiority is command line argument, environment variable and external file. (Specification through the command-line argument is strongest..)