This section contains a partial list of the _BPX environment variables.

_BPX_ACCT_DATA

Used by the exec callable service to change the account data of the new process image. For the rules on specifying account data, see the description of the exec callable service in z/OS UNIX System Services Programming: Assembler Callable Services Reference.

_BPX_BATCH_SPAWN

Specifies whether BPXBATCH is to use spawn instead of either fork or exec when executing programs.

SPAWN

Spawn is used to execute the program. Data definitions are carried over into the spawned process.

Guideline: When using _BPX_BATCH_SPAWN, you should consider two other environment variables that affect spawn behavior, _BPX_SHAREAS and BPX_SPAWN_SCRIPT. For more details, see BPXBATCH in z/OS UNIX System Services Command Reference.

No

Either fork or exec is used to execute the program. NO is equivalent to the default

_BPX_BATCH_UMASK

Modifies the permission bits on newly created files instead of using the default mask, if PGM has been defined. For more details, see BPXBATCH in z/OS UNIX System Services Command Reference.

_BPX_JOBNAME

Specifies the job name of the process, or changes the name. You can specify a string of 1-to-8 alphanumeric characters. Incorrect specifications are ignored. The environment variable is processed on the next spawn() or exec() service with the specified job name being used in the new image.

Requirement: Before the job name can be changed, the invoker must have appropriate privileges. The privileges include either superuser authority or READ permission to BPX.JOBNAME FACILITY class profile. The invoker must also be running in a space created by the fork callable services. Otherwise _BPX_JOBNAME is ignored.

_BPX_PTRACE_ATTACH

Used when you want to debug target programs.

YES

Programs that are invoked by the spawn, exec, and attach_exec callable services or by the C language spawn() and exec() functions are loaded into user-modifiable storage. Then those target programs can be debugged. The programs that are loaded into storage when the target program is executed, except for modules loaded from LPA, are also loaded.

_BPX_SHAREAS

Specifies whether the spawned child process is to be run in a separate address space from the login shell's address space or in the same address space. Use _BPX_SHAREAS is to improve performance in the z/OS® shell. The spawn callable service uses _BPX_SHAREAS when creating child processes.

Restriction: If tcsh is your login shell, do not use BPX_SHAREAS.

YES

The child process is created on a subtask in the parent's address space. If the request cannot be honored, the child is created in another address space.

NO

The child process is created in a new address space. NO is the default.

MUST

The child process is created on a subtask in the parent's address space. If the request cannot be honored, the request will not complete.

Restriction: Sometimes the YES and MUST values cannot be used. For more details, see the description of the spawn callable service in z/OS UNIX System Services Programming: Assembler Callable Services Reference.

For a discussion of the benefits and side effects of using BPX_SHAREAS, see Setting _BPX_SHAREAS and _BPX_SPAWN_SCRIPT.

_BPX_SPAWN_SCRIPT

Indicates whether the specified file is to be treated as a shell script. Use _BPX_SPAWN_SCRIPT to improve performance when running z/OS shell scripts.

YES

Treats the specified file as a shell script if it is not an executable process image file or a REXX exec. The shell is also executed to run the specified shell script. You can specify the path name for the shell in the SHELL environment variable on spawn's environment data list. You can also use /bin/sh as the default. The first argument passed when spawning a shell script should be the path name of the shell script.

NO

If the specified file is not an executable process image file or a REXX exec, the spawn callable service fails with the ENOEXEC return code. NO is the default if _BPX_SPAWN_SCRIPT is not specified or if it contains an unsupported value.

For more information about performance considerations when using _BPX_SPAWN_SCRIPT, see Setting _BPX_SHAREAS and _BPX_SPAWN_SCRIPT.

Restriction: If tcsh is your login shell, do not use _BPX_SPAWN_SCRIPT because it is only used for improving performance of /bin/sh scripts.

_BPX_TERMPATH

Enables shell scripts to determine if the user logged on from TSO, rather than from rlogin or telnet.

_BPX_UNLIMITED_OUTPUT

Specifies output limits that are processed only for non-local spawn requests.

Rule: To use _BPX_UNLIMITED_OUTPUT, the caller must be a superuser or be permitted to the BPX.UNLIMITED.OUTPUT FACILITY class profile with READ access or greater.

YES

Specifies unlimited spooled output.

NO

Specifies that the default spooled output limits is to be used. Not defining or specifying a value is the equivalent of specifying NO and the defaults limits are not overridden.

_BPX_USERID

Specifies that the child process is to be created with the specified MVS™ user identity. _BPX_USERID is used by the spawn callable service.

Example: _BPX_USERID=DANIEL creates a child process with the DANIEL user ID to run the spawned program. Authorization for use of the _BPX_USERID is the same as that for the setuid() function. Child processes running with a different user identity than the parent's are always created in a new address space. _BPX_SHAREAS is ignored in this case.

Using _BPX_USERID can improve performance for a program. The program can establish a new user identity for the child that runs the spawned program, instead of creating a child with the original user identity and having the child establish a new user identity. Otherwise, that program would have forked a new address space before establishing a new user identity for the new address space by issuing initgroups(), setgid(), and setuid(), and so forth. Then it would have done an exec() of the program that was to run under the new user identity.

Guideline: Be careful when using _BPX_USERID. Typically, environment variables passed on spawn are still active in the child process. If _BPX_USERID is set in the parent and not cleared in the child, any spawn calls issued by the child picks up the same _BPX_USERID setting. This behavior is likely to be undesirable. The support that allows the specification of a user ID in the inheritance structure on spawn does not have this drawback.