Performance: Running executable files

Note: This information is directed toward users of the z/OS® shell. Most examples pertain to the z/OS shell and not to the tcsh shell.

A process is a collection of threads that execute within an address space, along with the required system resources. A user's login shell is one example of a process.

The OMVS command creates two processes per login: a process to control the terminal and a process for the login shell.
rlogin and telnet logins each create two processes: one to control the socket connection to the user, another for the login shell.
Communications Server logins require only one process per login. Consequently, there is no method for requesting a shared address space for the Communications Server login shell.

Most utilities invoked from the shell command line run in new processes that the shell creates.

There is a system-wide limit on:

The number of z/OS UNIX processes across the system
The number of z/OS UNIX processes per user

For a discussion of these limits, see the section on defining system limits in z/OS UNIX System Services Planning.

The shell, and other z/OS UNIX commands and daemons, can assign multiple processes to the same MVS™ address space; this is called a shared address space. Using a shared address space offers these advantages:

A new process in the same address space can be started more quickly than a new process in another address space.
A new process in the same address space requires fewer system resources (storage, for example) than a new process in another address space.

For rlogin, the system administrator must update /usr/sbin/inetd.conf by adding -m to the rlogind entry to enabled shared address space. When -m is added, the socket connection process and the login shell process share the same address space.

For the OMVS command, use the SHAREAS keyword to enable shared address space. When the SHAREAS keyword is used, the login shell process is nested in the user's TSO address space. Any other login shells started with the OMVS OPEN subcommand are also nested in the user's TSO address space. (With NOSHAREAS, other login shells started with the OMVS OPEN subcommand will each consume another address space.)

To enable shared address space for the shell, issue the command

export _BPX_SHAREAS=YES

interactively, or place it in your $HOME/.profile. All simple commands (commands that are run in the foreground and not in a pipeline) will then run in processes nested in the shell's address space. If the _BPX_SHAREAS variable is not set, or if it is not set to the value YES, the shell creates all processes in separate address spaces. No matter how the shell is started (with or without shared address space enabled), you must set _BPX_SHAREAS=YES if processes started by the shell itself are to run in processes nested in the shell's address space.

User applications can also use shared address spaces. See spawn (BPX1SPN, BPX4SPN) — Spawn a process and attach_exec (BPX1ATX, BPX4ATX) — Attach a z/OS UNIX program in z/OS UNIX System Services Programming: Assembler Callable Services Reference for details.

Some processes cannot execute correctly in a shared address space. For example, if a process needs to reserve MVS system resources that are common to all processes in an MVS address space, it must run by itself. If two processes using the same MVS resource attempt to execute concurrently in the same address space, they will compete for these resources, causing at least one of them to fail. When a potential storage shortage is detected, the new processes are created in their own address spaces, even if _BPX_SHAREAS=YES is present in the invoker's environment. For more details about these restrictions, see the descriptions of the spawn() function and the BPX1SPN callable service.