Statements and parameters for BPXPRMxx

For guidance information about selecting values for the statements, see the section on customizing z/OS® UNIX in z/OS UNIX System Services Planning.

ALTROOT FILESYSTEM('fsname') PARM('parameter') MOUNTPOINT('pathname')

Specifies the alternate sysplex root file system that is to automatically replace the current sysplex root file system when the current one becomes unowned. It is mutually exclusive with ALTROOT NONE.

When the replacement occurs, the alternate sysplex root file system is unmounted and then mounted again as the current sysplex root on all systems in the shared file system configuration. If the replacement is successful, the failed sysplex root is unmounted.

The alternate sysplex root file system is always mounted in the READ mode and designated as AUTOMOVE=YES when it becomes the current sysplex root file system. The previous mount mode and AUTOMOVE settings of the alternate sysplex root and the failed sysplex root are ignored. The mount parameters are preserved when the alternate sysplex root file system becomes the current sysplex root file system.

To manually replace the failed or failing sysplex root file system, use the MODIFY OMVS,NEWROOT operator command with the COND=FORCE option. To validate the syntax of the ALTROOT statement, use the SETOMVS SYNTAXCHECK operator command. See the Steps for dynamically replacing the sysplex root file system topic in z/OS UNIX System Services Planning for step-by-step instructions of manually replacing the failed or failing sysplex root. For more information about the mentioned system commands, see z/OS MVS System Commands.

FILESYSTEM('fsname'): The name of the alternate sysplex root file system.
PARM('parameter'): The parameter to be passed directly to the file system type.
MOUNTPOINT('pathname'): The absolute path name, or a symbolic link that resolves to the path name of the directory onto which the file system is to be mounted. MOUNTPOINT must be specified in the ALTROOT statement. The mount point for the alternate sysplex root file system must reside in the root directory of the current sysplex root file system, otherwise mount of the ALTROOT will fail. The absolute path name can be up to 64 characters.

ALTROOT NONE

Removes the ALTROOT support and deletes any outstanding eventual action messages. It is mutually exclusive with ALTROOT FILESYSTEM(). It does not unmount the ALTROOT file system that was established by using the ALTROOT FILESYSTEM statement. The ALTROOT file system is left unmounted as a regular file system.

AUTHPGMLIST('/etc/authfile')|NONE

Specifies the path name of a z/OS UNIX file that contains the lists of APF-authorized path names and program names. If you do not specify a value for AUTHPGMLIST, or if you specify NONE, invocations of APF-authorized and program controlled programs will not be checked against a list of authorized programs or authorized path names. If you specify a path name for the AUTHPGMLIST parameter, the system checks this list during hfsload, exec, and spawn processing. If the target program of an exec or spawn has an authorization code of 1 (AC=1), then that program name must appear in the authorized program list.

Use the SETOMVS or SET OMVS command to dynamically change the value of AUTHPGMLIST. To make a permanent change, edit the BPXPRMxx member that will be used for IPLs.

For more information, see z/OS UNIX System Services Planning.

AUTOCVT(ALL|ON|OFF)

Activates and deactivates automatic conversion of I/O data using coded character sets for the program and its associated files. The coded character set identifiers (CCSIDs) are specified by the program or by setting the appropriate environment variables at run time. The system AUTOCVT indicator can be overridden by individual programs at a thread or file descriptor level; AUTOCVT is a controlling global switch only for existing programs that do not explicitly establish their own conversion environment.

ALL: Enables Unicode Services conversion of data during read and write I/O operations.
OFF: Automatic conversion is not enabled.
ON: Enables Enhanced ASCII conversion of data during read and write I/O operations. Conversion is limited to the EBCDIC (1047) and ASCII (819) code pages.

Default: OFF

You can use the SETOMVS or SET OMVS commands to change the value of AUTOCVT between ALL, ON, and OFF. Changing this conversion mode does not affect conversion of opened files for which I/O has already started.

Guideline: When AUTOCVT(ALL) or AUTOCVT(ON) is set, every read and write operation for a file must be checked to see if conversion is necessary, which incurs a performance penalty, even if no conversion occurs. If possible, keep AUTOCVT(OFF) and have each program enabled for conversion. To do this, set the compile or runtime environment variables that control conversion or use programmable function, as described in z/OS UNIX System Services Planning.

Automatic conversion can also be controlled individually by a program with one of the following flags in the thread Thli control block (BPXYTHLI):

ThliCvtOn - Activates automatic conversion for this thread.
ThliCvtOff - Deactivates automatic conversion for this thread.

Both bits must not be on at the same time.

Automatic conversion is accomplished between programs and files that are tagged with different CCSIDs when a conversion table exists for that CCSID pair in the system. CCSID values are defined in Character Data Representation Architecture. For information about supported Unicode Services CCSIDs, see z/OS Unicode Services User's Guide and Reference.

AUTOMOVE|NOAUTOMOVE

The AUTOMOVE and NOAUTOMOVE parameters apply only in a sysplex where systems are participating in shared file system. They indicate what happens to the ownership of the file system when a shutdown, PFS termination, dead system takeover, or file system move occurs.

AUTOMOVE: Indicates that ownership of the file system automatically changes to another system that is participating in the shared file system.
NOAUTOMOVE: Indicates that ownership of the file system is not moved if the owning system goes down; as a result, the file system becomes inaccessible. When you specify NOAUTOMOVE, the file system becomes inaccessible when the owning system goes down. But it still exists in the file system hierarchy. The file system remains unowned until the original owing system re-IPLs.

Use AUTOMOVE for the sysplex root file system and the version file system. For file systems that are associated with a single system, specify UNMOUNT; this includes /etc, /tmp, /var, /dev, and other system-specific file systems. For descriptions of the sysplex root, system-specific, and version file systems, see Sharing file systems in a sysplex in z/OS UNIX System Services Planning.

To ensure that the root is always available, use the default.

Default: AUTOMOVE

CTRACE(parmlib_member_name)

Specifies the parmlib member that contains the initial tracing options to be used for the z/OS UNIX component. Use this statement to provide tracing while the kernel is starting and to avoid having to issue a TRACE operator command to set tracing options.

Default: CTIBPX00

FILESYSTYPE TYPE(type_name) ENTRYPOINT(entry_name) PARM('parm') ASNAME(proc_name[,'start_parms'])

Specifies the type of file system that is to be started. BPXPRMxx can contain more than one FILESYSTYPE statement.

When SYSPLEX(YES) is specified, each FILESYSTYPE in use within the participating shared file system group must be defined for all systems that are participating in shared file system. The easiest way to accomplish this is by having a single BPXPRMxx member that contains file system information for each system that is participating in shared file system. If you decide to define a BPXPRMxx for each system, the FILESYSTYPE statements must be identical on each system. For more information about shared file system, see z/OS UNIX System Services Planning.

Any facilities that are required for a particular FILESYSTYPE must be initiated on all systems that are participating in shared file system. For example, NFS requires TCP/IP, so if you specify an NFS FILESYSTYPE, you must also initialize TCP/IP on NFS initialization.

The SETOMVS RESET command can be used to dynamically specify new FILESYSTYPE statements. To make a permanent change, edit the BPXPRMxx member that is used for IPLs. For more information, see Dynamically adding FILESYSTYPE statements in BPXPRMxx in z/OS UNIX System Services Planning.

The parameters are as follows:

ASNAME(proc_name[,'start_parms'])

proc_name specifies the name of a procedure in SYS1.PROCLIB that is to be used to start the address space that is initialized by the physical file system (PFS). Specify ASNAME for any PFS that does not run in the kernel address space. The name that you specify is also used for the name of the address space.

start_parms is an optional quoted string that is to be appended to the proc_name when the address space is started. The string can be up to 100 characters long. The start_parms are not validated; they are just passed to the system when the address space is started with an internal command. Refer to the START command in z/OS MVS System Commands or the ASCRE macro in z/OS MVS Programming: Authorized Assembler Services Reference ALE-DYN.

By default the address space started with ASNAME is started under JES, but this can be changed by including the additional start_parms SUB=MSTR.

ASNAME is an optional parameter. proc_name is 1 to 8 characters; the system converts the name to uppercase. If you do not specify ASNAME, or specify proc_name as the name of the kernel address space, the PFS is initialized in the kernel address space.

Refer to the documentation for the specific physical file system for valid ASNAME operands.

PARM('parm')

Provides a parameter to be passed directly to the file system type. The parameter format and content are specified by the file system type.

PARM is an optional parameter. The parameter is up to 1024 characters long; the characters can be in uppercase, lowercase, or both. The parameter must be enclosed in single quotation marks.

For information about specifying the TFS configuration parameters, see the section on parameter key options for the FILESYSTYPE statement in z/OS UNIX System Services Planning. For example:

-ea count: Allows the TFS file system to automatically grow count times.
-em count: Allows the TFS file system to manually grow count times.

If the physical file system specified does not expect a PARM operand, it ignores all PARM operands.

PRM=(aa, bb, ..., zz) is valid for the z/OS File System (zFS).

SYNCDEFAULT(t), VIRTUAL(max), FIXED(min), RNODEWAIT(t), WAITABEND, and BUFFERMONITOR are valid only when ENTRYPOINT is GFUAINIT. FSFULL(threshold,increment) is supported by HFS, TFS, and zFS.

Note: If a syntax error is found in any of these four parameters (SYNCDEFAULT, VIRTUAL, FIXED, or FSFULL), the system issues an error message issued and set all four parameters to the default values.

PRM=(aa, bb, ..., zz) is used to define the IOEPRMyy members of the logical parmlib concatenation for specifying zFS configuration parameters, where:
- aa, bb, ..., zz specify the suffixes of the IOEPRMxx parmlib members in the order in which they are to be concatenated. Up to 32 suffixes can be specified. Suffixes must be in uppercase. Defining an IOEFSPRM configuration file with an IOEZPRM DD card in the zFS procedure will override the PRM specification (that is, cause it to be ignored). See Specifying the IOEPRMxx concatenation for examples and additional syntax information.
SYNCDEFAULT(t)
- t specifies the number of seconds used as a default for the sync daemon interval. When the sync daemon is active, the metadata for a file system is hardened. Setting t to 0 indicates that the file system should harden metadata synchronously with syscall requests.
- Sync interval values are rounded up to the next 30-second value. For example, specifying 31 seconds results in a sync interval of 60 seconds.
- The maximum value that can be specified for t is 65534. Values between 65534 and 99999 are rejected.
- A value of 99999 specifies that no sync daemon intervals are specified, and thus, the metadata is not hardened.
- The default is 60 seconds.
VIRTUAL(max)
- max specifies the maximum amount of virtual storage (in megabytes) that file system data and metadata buffers should use.
- If you do not set a value for max, the system assigns a default value that is equal to half the amount of real storage available to the system when z/OS is initialized. See z/OS UNIX System Services Planning for more information about the VIRTUAL(max) parameter.
FIXED(min)
- min specifies the amount of virtual storage (in megabytes) that is fixed when z/OS is initialized and remains fixed even if file system activity drops to zero. min must be less than or equal to VIRTUAL(max).
- min cannot exceed 50% of real storage available to the system. If the allowed amount of storage is exceeded, an informational message is issued and min is set to 50% of real storage. The minimum limit can be changed dynamically by invoking the confighfs shell command. See z/OS UNIX System Services Command Reference for more information about the confighfs shell command.
- The default is 0.
FSFULL(threshold,increment)
- threshold specifies the percentage of the file system (HFS, TFS, or zFS) capacity at which an operator message is generated. The default is 100%.
- increment specifies the percentage of change above the file system capacity at which an operator message is generated. Messages are generated by either an increase or decrease greater than increment. The default is 5%.
  You can specify threshold and increment values for the file system. The values can also be set on the MOUNT command for a specific file system. Parameters on the MOUNT command override parmlib values. If no values are specified in either place, no threshold checking is done. If a threshold value is specified but no increment is given, the increment defaults to 5%.The increment value applies both to upgrading the message when the file system continues to fill and to removing the message when more space becomes available due to either deleting files, or to extending the file system. The values are in terms of percent full. The values that are applied to a file system can be changed only when the file system is mounted.
BUFFERMONITOR
- If this keyword is specified, the virtual storage monitor is started. IGW029I messages are issued when the monitor is started or ended. IGW029I messages are also issued when the storage is above 80% and 90% of the maximum storage value. Use the z/OS UNIX confighfs command to query the current and maximum storage values. The command can be used to set a new maximum storage value.

TYPE(type_name)

Specifies the name of the file system type that is to control the file system. TYPE is a required parameter. The name is 1 to 8 characters; the system converts the name to uppercase. In the FILESYSTYPE statement, specify one of the following types of the file system:

HFS for a hierarchical file system (HFS).
zFS for a z/OS File System (zFS).
NFS for accessing remote files.
TFS for a temporary file system (TFS).

For planning information, see FILESYSTYPE in z/OS UNIX System Services Planning.

FORKCOPY(COW|COPY)

Specifies how user storage is to be copied from the parent process to the child process during a fork() system call.

COPY: Specifies that fork() immediately copies the parent storage to the child, whether the SOP is available or not. Use this option to avoid any additional ESQA use in support of fork.
COW: Specifies that all fork() calls are processed with the copy-on-write mode if the suppression-on-protection (SOP) hardware feature is available. Before the storage is modified, both the parent and child process refer to the same view of the data. The parent storage is copied to the child only if either the parent or the child modifies the storage.
FORKCOPY(COW) causes the system to use the ESQA to manage page sharing and is the default.

Follow these guidelines:

If the runtime library is in the link pack area, specify FORKCOPY(COPY).
If the runtime library is not in the link pack area, specify FORKCOPY(COW).

Default: COW

Use the SETOMVS or SET OMVS command to dynamically change the value of FORKCOPY. To make a permanent change, edit the BPXPRMxx member used for IPLs.

IPCMSGNIDS(nnnnn)

Specifies the maximum number of unique system-wide message queues.

Value range: group_name nnnnn is a decimal value from 1 to 20000.

Default: 500

Use the SETOMVS or SET OMVS command to change the value of IPCMSGNIDS dynamically. The new minimum is the current value. The new maximum is calculated as follows:

MIN(initial maximum,MAX(4096,3*initial value))

You can increase but not decrease the value, as described in z/OS UNIX System Services Planning.

IPCMSGQBYTES(nnnnn)

Specifies the maximum number of bytes in a single message queue.

Value range: nnnnn is a decimal value from 0 to 2147483647.

The high end of this range is not obtainable due to storage constraints. The actual maximum range varies due to storage allocation and system usage.

Default: 2147483647 (2 G).

Use the SETOMVS or SET OMVS command to change the value of IPCMSGQBYTES dynamically.

IPCMSGQMNUM(nnnnn)

Specifies the maximum number of system-wide messages for each queue.

Value range: nnnnn is a decimal value from 0 to 2147483647.

The high end of this range is not obtainable due to storage constraints. The actual maximum range varies due to storage allocation and system usage.

Default: 10000

Use the SETOMVS or SET OMVS command to change the value of IPCMSGQMNUM dynamically.

IPCSEMNIDS(nnnnn)

Specifies the maximum number of unique system-wide semaphore sets.

Value range: nnnnn is a decimal value from 1 to 20000.

Default: 500

You can change the value of IPCSEMNIDS dynamically with the SETOMVS or SET OMVS command, as described in z/OS UNIX System Services Planning.

IPCSEMNOPS(nnnnn)

Specifies the maximum number of operations for each semop call.

Value range: nnnnn is a decimal value from 0 to 32767.

Default: 25

You can change the value of IPCSEMNOPS dynamically with the SETOMVS or SET OMVS command.

IPCSEMNSEMS(nnnnn)

Specifies the maximum number of semaphores for each semaphore set.

Value range: nnnnn is a decimal value from 0 to 32767.

Default: 1000

You can change the value of IPCSEMNSEMS dynamically with the SETOMVS or SET OMVS command.

IPCSHMMPAGES(nnnnn)

Specifies the maximum number of pages for shared memory segments.

Value range: nnnnn is a decimal value from 1 to 4 petabytes (that is, 4 * 1 125 899 906 842 624).

If you obtain memory segments below the 2-gigabyte address range, then a realistic maximum is about 1.5 gigabytes; the actual maximum range varies due to storage allocation and system usage. If you obtain memory segments above the 2-gigabyte address range, the maximum depends on the IEASYS HVSHARE parameter, which specifies the size of the high virtual shared area.

Default: 25600

Use the SETOMVS or SET OMVS command to change the value of IPCSHMMPAGES dynamically.

IPCSHMNIDS(nnnnn)

Specifies the maximum number of unique system-wide shared memory segments.

Value range: nnnnn is a decimal value from 1 to 20000.

Default: 500

Use the SETOMVS or SET OMVS command to change the value of IPCSHMNIDS dynamically. The new minimum is the same as the current value. The new maximum is calculated as follows:

MIN(initial maximum,MAX(4096,3*initial value))

You can increase but not decrease the value, as described in z/OS UNIX System Services Planning.

IPCSHMNSEGS(nnnnn)

Specifies the maximum number of attached shared memory segments for each address space.

Value range: nnnnn is a decimal value from 0 to 1000.

Default: 10

You can change the value of IPCSHMNSEGS dynamically using the SETOMVS or SET OMVS command.

IPCSHMSPAGES(nnnnn)

Specifies the maximum number of system-wide shared pages that are created by calls to the fork and 31-bit shmat functions.

You can increase, but not decrease, the value, as described in z/OS UNIX System Services Planning. Shared memory segments that are obtained above the 2-gigabyte range in 64-bit programs do not affect this limit.

Value range: nnnnn is a decimal value from 0 to 2621440.

You can set a denomination (or multiplier) value when you define this value. The C suffix can have a one-character value as presented in Table 1, but must not exceed the parameter-specific upper limit. The denomination value is retained and is used again within a subsequent D OMVS command.

Default: 262144

You can change the value of IPCSHMSPAGES dynamically with the SETOMVS or SET OMVS command. The new minimum is the same as the current value. The new maximum is calculated as follows:

MIN(initial maximum,MAX(4096,3*initial value))

You can increase but not decrease the value, as described in z/OS UNIX System Services Planning.

Because each page of shared storage requires the associated consumption of extended system queue area (ESQA) storage, limiting the shared storage usage provides a way to limit the ESQA usage by z/OS UNIX users. If you use the __IPC_MEGA or __MAP_MEGA options, then the shared pages limits are not affected because MEGA does not affect the system ESQA overhead.

KERNELSTACKS(ABOVE|BELOW)

Specifies whether to allocate kernel stacks from above or below bar storage. When the kernel stacks are allocated from kernel private storage that is below the bar, the number of threads running in the kernel is limited to about 30,000. Specifying KERNELSTACKS(ABOVE) increases thread limit to a maximum of 500,000; the actual amount will vary, depending on work load and system configuration. Usage of real storage in the kernel address space is also increased.

ABOVE: All kernel stacks are allocated above the bar.
BELOW: All kernel stacks are allocated below the bar.

Default: BELOW

Notes:

You cannot change the value of KERNELSTACKS dynamically with thethe SETOMVS or SET OMVS command.
You cannot change the value of KERNELSTACKS on an OMVS RESTART.
Any changes to the BPXPRMxx member for KERNELSTACKS will not take effect until the next IPL.

LIMMSG(

Specifies how console messages that indicate when parmlib limits are reaching critical levels are to be displayed.

ALL

Displays console messages for both the system limits and the process limits, regardless of which process reaches a process limit.

NONE

Does not display console messages when any of the parmlib limits are reached.

SYSTEM

Displays console messages for all processes that reach system limits. In addition, messages are displayed for each process limit of a process if any of the following conditions are met:

The process limit or limits are defined in the OMVS segment of the owning user ID
The process limit or limits were changed with a SETOMVS PID=pid,process_limit

Default: NONE

LOSTMSG(ON|OFF)

LOSTMSG(ON) detects lost and duplicate XCF messages in a shared file system configuration. It is ignored if the file system does not have a shared file system configuration; for example, when SYSPLEX(NO) is specified. While LOSTMSG can be specified differently for each member in the sysplex, the same LOSTMSG setting should be specified throughout the sysplex. To disable the detecting of lost and duplicate messages, specify LOSTMSG(OFF).

Do not use LOSTMSG(ON) when z/OS UNIX sysplex traffic is high, such as when many file systems that are not sysplex-aware are being accessed remotely because performance might be affected.

Default: ON

MAXASSIZE(nnnnn)

Specifies the RLIMIT_AS resource values that will be established as the initial values for new processes. RLIMIT_AS indicates the address space region size. For more information about RLIMIT_AS, refer to the description of setrlimit in z/OS UNIX System Services Programming: Assembler Callable Services Reference.

The soft limit is obtained from MVS™; if it is greater than the MAXASSIZE value, the soft limit is set to the hard limit. This value is also used when processes are initiated by a daemon process using an exec() after setuid(). In this case, both the RLIMIT_ AS hard and soft limit values are set to the MAXASSIZE specified value.

When processes are initiated by a daemon process using an exec()after setuid(), this value is used. Therefore, MAXASSIZE will be the region size for all processes created through rlogin or telnet. In this case, both the RLIMIT_AS hard and soft limit values are set to the MAXASSIZE value.

A superuser can override this value by specifying a new region size in the spawn inheritance structure on __spawn(). Or you can change the value of MAXASSIZE dynamically by using the SETOMVS or SET OMVS command. This change only affects the new processes that are created after the change was made.

Note: The IEFUSI user exit can modify the region size of an address space. Users are strongly discouraged from altering the region size of address spaces in the OMVS subsystem category.

Value range: nnnnn is a decimal value from 10485760 (10 megabytes) to 2147483647 (2 gigabytes).

Default: 209715200

Use the SETOMVS or SET OMVS command to dynamically increase or decrease the value of MAXASSIZE. To make a permanent change, edit the BPXPRMxx member that is used for IPLs.

The MAXASSIZE value limits the combined size of above and below the 16 M line storage. If MAXASSIZE is greater than LDALIMIT (the <16M limit), then the LDAELIM (the >16M limit) is set to MAXASSIZE - LDALIM.

For planning information, see MAXASSIZE in z/OS UNIX System Services Planning.

MAXCORESIZE(nnnnn)

Specifies the RLIMIT_CORE soft and hard resource values that will be established as the initial values for new processes. RLIMIT_CORE indicates the maximum core dump file size (in bytes) that a process can create. It also specifies the limit when they are initiated by a daemon process using an exec() after a setuid(). For more information about RLIMIT_CORE, see the description of setrlimit() in z/OS UNIX System Services Programming: Assembler Callable Services Reference.

Value range: nnnnn is a decimal value from 0 to 2147483647 (2 gigabytes).

When you define the MAXCORESIZE value, you can set a denomination (or multiplier) value. The C suffix can have a one-character value as presented in Table 1, but must not exceed the parameter-specific upper limit. The denomination value is retained and is used again within a subsequent D OMVS command.

Default: 4194304 (4 megabytes). Specifying a value of 2147483647 (2 gigabytes) indicates an unlimited core file size.

Use the SETOMVS or SET OMVS command to dynamically increase or decrease the value of MAXCORESIZE. To make a permanent change, edit the BPXPRMxx member that is used for IPLs.

MAXCPUTIME(nnnnn)

Specifies the RLIMIT_CPU resource values that will be established as the initial values for new processes. RLIMIT_CPU indicates the CPU time, in seconds, that a process can use. For more information about RLIMIT_CPU, refer to the description of setrlimit() in z/OS UNIX System Services Programming: Assembler Callable Services Reference.

If the soft limit value from MVS is greater than the MAXCPUTIME value, the soft limit is set to the hard limit. This value is also used when processes are initiated by a daemon process using an exec() after setuid(). In this case, both the RLIMIT_CPU hard and soft limit values are set to the MAXCPUTIME value.

A superuser can override this value by specifying a new time limit in the spawn inheritance structure on __spawn().

For processes that are running in or forked from TSO or BATCH, the MAXCPUTIME value has no effect. The TIME limit is inherited from the parent. If a TIME parameter is specified on the JCL for the started task, then that value is used. If not, then the TIME value is taken from the JES default TIME value.

For processes created by the rlogind command or other daemons, MAXCPUTIME is the time limit for the address space.

Specifying a MAXCPUTIME or CPUTIMEMAX of 86400 seconds disables the JWT, SWT, or TWT timeout the same way that JCL TIME=1440 does. See Statements and parameters for SMFPRMxx for details on the JWT, SWT, and TWT parameters.

Value range: nnnnn is a decimal value from 7 to 2147483647 seconds.

Default: 1000

Use the SETOMVS or SET OMVS command to dynamically increase the value of MAXCPUTIME. To make a permanent change, edit the BPXPRMxx member that will be used for IPLs.

For planning information, see MAXCPUTIME in z/OS UNIX System Services Planning.

MAXFILEPROC(nnnnnn)

Specifies the maximum number of descriptors for files, sockets, directories, and any other file system objects that a single process can have concurrently active or allocated. MAXFILEPROC is the same as the OPEN_MAX variable in the POSIX standard.

Note: nnnnnn is a decimal value from 3 to 524287.

64000.

Use the SETOMVS or SET OMVS command to dynamically increase or decrease the value of MAXFILEPROC. To make a permanent change, edit the BPXPRMxx member that is used for IPLs.

On the ADDUSER command, you can increase the maximum number of open descriptors on a per process basis. The FILEPROCMAX parameter on the ADDUSER command overrides the MAXFILEPROC parameter in the BPXPRMxx profile.

For planning information, see MAXFILEPROC in z/OS UNIX System Services Planning.

MAXFILESIZE(nnnnn|NOLIMIT)

pecifies the RLIMIT_FSIZE soft and hard resource values that will be established as the initial values for new processes. RLIMIT_FSIZE indicates the maximum file size (in 4 KB increments) that a process can create. It also specifies the limit when they are initiated by a daemon process using an exec() after a setuid(). For more information about RLIMIT_FSIZE, see the description of setrlimit() in z/OS UNIX System Services Programming: Assembler Callable Services Reference.

Value range: nnnnn is a decimal value from 0 to 2147483647, which indicates an unlimited file size. If MAXFILESIZE is not specified or MAXFILESIZE(NOLIMIT) is specified, there is no limit to the size of files created, except for the architectural limit of the system.

You can set a denomination (or multiplier) value when defining this value. The C suffix can have a one-character value as presented in Table 1, but must not exceed the parameter-specific upper limit. The denomination value is retained and is used again within a subsequent D OMVS command.

If you specify 0, the process does not create any files. Omitting this statement indicates an unlimited file size.

Default: NOLIMIT

Use the SETOMVS or SET OMVS command to dynamically increase or decrease the value of MAXFILESIZE. To make a permanent change, edit the BPXPRMxx member that is used in IPLs.

MAXIOBUFUSER(nnnnn)

Specifies that maximum amount of persistent I/O virtual storage that z/OS UNIX obtains on behalf of a user when a process performs I/O in a Unicode Services conversion environment (that is, the AUTOCVT setting is ALL). This storage remains allocated for the life of an open file. The amount that is allocated for each open depends on the CCSID of the file and the size of a read or write requests that are used by the process. The limit does not apply to UID 0 processes.

Value range: 0 to 2 G, representing the number of megabytes of storage. Thus, 2 G represents 2G x 1M = 2P (petabytes) of storage.

Default: 2048 (equivalent to 2 G of storage)

MAXMMAPAREA(nnnnn)

Specifies the maximum amount of data space storage space (in pages) that can be allocated for memory mappings of z/OS UNIX files. Storage is not allocated until the memory mapping is active.

Using memory map services causes a large amount of system memory to be consumed. For each page (4 KB) that is memory-mapped, 96 bytes of ESQA are consumed when a file is not shared with any other users. When a file is shared by multiple users, each user after the first causes an additional 32 bytes of ESQA to be consumed for each shared page. Assuming that the default of 40960 pages is taken, and assuming that no sharing is done by mmap() users, a maximum of 3840 KB of ESQA could be consumed. The ESQA storage is consumed when the mmap() function is invoked rather than when the page is accessed by the memory mapping application program.

If you have applications using the __MAP_MEGA option, you can map very large files without the system overhead in ESQA. For more information, see Using extended system queue area (ESQA) in z/OS UNIX System Services Planning.

Value range: nnnnn is a decimal value from 1 to 16777216.

Default: 40960

You can change the value of MAXMMAPAREA dynamically using the SETOMVS or SET OMVS command. To make a permanent change, edit the BPXPRMxx member that will be used for IPLs.

For planning information, see MAXMMAPARE in z/OS UNIX System Services Planning.

MAXPIPEUSER(nnnnn)

Specifies the maximum number of z/OS UNIX named or unnamed pipes that a real UID can open concurrently. The value only applies to non-UID=0 users. For UID=0 users, the MAXPIPERUSER limit of 8730 is always enforced.

Value range: nnnnn is a decimal value from 256 to 8730.

Default: 8730

Use the SETOMVS or SET OMVS command to dynamically increase or decrease the value of MAXPIPEUSER. To make a permanent change, edit the BPXPRMxx member that will be used for IPLs.

For planning information, see z/OS UNIX System Services Planning.

Syntax example in BPXPRMxx: MAXPIPEUSER(8730)

MAXPROCSYS(nnnnn)

Specifies the maximum number of processes that the system allows.

Value range: nnnnn is a decimal value from 5 to 32767.

Default: 900

You can use the SETOMVS or SET OMVS command to dynamically increase or decrease the value of MAXPROCSYS. To make a permanent change, edit the BPXPRMxx member that is used for IPLs.

If you are using SETOMVS or SET OMVS to change the value, the new value must be within a certain range, or you will get an error message. The range that you can use has a minimum value of 5; the maximum value is based on the following calculation:

MIN(32767,MAX(4096,3*initial value))

The initial value is the MAXPROCSYS value that was specified during BPXPRMxx initialization. You cannot use a value less than 5. If you want to use a value greater than the current maximum (as calculated by the formula) but lower than the initial maximum (32767), you must change the value in BPXPRMxx and re-IPL. For an example of how to calculate the maximum value in the range, see the section on dynamically changing certain BPXPRMxx parameter values in z/OS UNIX System Services Planning. For planning information, also see MAXPROCSYS in z/OS UNIX System Services Planning.

MAXPROCUSER(nnnnn)

Specifies the maximum number of processes that a single z/OS UNIX user ID can have concurrently active, regardless of how the processes were created. MAXPROCUSER is the same as the CHILD_MAX variable in the POSIX standard.

A value of 25 is required for FIPS 151-2 compliance and a value of 16 is required for POSIX.1 (ISO/IEC 9945-1:1990[E] IEEE Std 1003.1-1990) standard compliance.

The number of processes is tracked by user ID (UID). When a user attempts to create a new process, the limit value for the user (defined by either the user profile or the default OPTN value) is compared to the value maintained for the user's UID. If the user maximum is larger than the current process count for the UID, the user can create another process. If not, the user is not allowed to create a new process. For example, if user A, with a user-defined limit of 10, tries to create a process and the UID limit is already 12, user A is not allowed to create the new process. Since only 12 processes are currently created, user B, with a user-defined limit of 20, is allowed to create a new process.

Use the SETOMVS or SET OMVS command to dynamically increase or decrease the MAXPROCUSER values. To make a permanent change, edit the BPXPRMxx member that is used for IPLs.

There are certain cases when a new process can be created with a UID that has already reached the MAXPROCUSER number of processes. Super users (with UID=0) and processes blind dubbed with the default OMVS segment are not limited by MAXPROCUSER.

For planning information, see MAXPROCUSER in z/OS UNIX System Services Planning.

Value range: nnnnn is a decimal value from 3 to 32767.

Default: 25

MAXPTYS(nnnnn)

Specifies the maximum number of pseudoterminals (pseudo-TTYs or PTYs) for the system.

Value range: nnnnn is a decimal value from 1 to 10000.

Default: 800

You can use the SETOMVS or SET OMVS command to dynamically increase the value of MAXPTYS. To make a permanent change, edit the BPXPRMxx member that is used for IPLs.

If you are using SETOMVS or SET OMVS to change the value, the new value must be within a certain range. If it is outside the range, you will get an error message. To use a value that is outside this range, you must change the MAXPTYS specification in BPXPRMxx and re-IPL. The range's minimum value is 1 and the maximum is based on the following calculation:

MIN(10000,MAX(256,2*initial value)

The initial value is the MAXPTYS value that was specified during BPXPRMxx initialization. For an example of how to calculate the maximum value in the range, see the section on dynamically changing BPXPRMxx values in z/OS UNIX System Services Planning.

For planning information, see MAXPTYS in z/OS UNIX System Services Planning.

MAXQUEUEDSIGS(nnnnnn)

Specifies the maximum number of signals that z/OS UNIX allows to be concurrently queued within a single process.

Value range: nnnnnn is a decimal value from 1 to 100000.

Default: 1000

You can change the value of MAXQUEUEDSIGS dynamically by using the SETOMVS or SET OMVS command. To make a permanent change, edit the BPXPRMxx member that will be used for future IPLs.

MAXSHAREPAGES(nnnnn)

Specifies the maximum amount of shared system storage pages that can be used by z/OS UNIX functions. The purpose of MAXSHAREPAGES is to limit the amount of ESQA storage necessary to maintain the shared pages. See Predicting and limiting ESQA usage in z/OS UNIX System Services Planning for the formula to determine the maximum amount of ESQA that is consumed during loading user-shared libraries.

The usage of shared pages is helpful but not critical to the loading of user shared library modules, ptrace, and fork; it serves to increase performance but does not affect functionality. As the amount of shared pages being used reaches certain limits, fewer functions are allowed to continue using them. User shared library loads, ptrace, and fork stop using shared pages when the limit reaches 60% (the only time shared storage is used by the fork service is when FORKCOPY(COW) is specified), mmap stops at 80%, and shmat, the most critical function, uses shared pages until their total capacity has been reached. If while running a 64–bit program, you allocate shared memory segments above the bar by using the shmget() service, the shared page limit is not affected.

Note: Evaluate adjusting MAXSHAREPAGES on an active system. Dynamically decreasing the number of pages available to ESQA for active work can cause errors. This is due to the fact that for those jobs, the ESQA limit might now be reached or exceeded. It is possible that shared programs will not be able to be loaded and fork() might not succeed. This situation will exist until the workload adjusts to the new lower limit.

Value range: nnnnn is a decimal value from 0 to 32768000 specifying a number of 4K pages.

Default: 131072

Use the SETOMVS or SET OMVS command to dynamically increase or decrease the MAXSHAREPAGES value. To make a permanent change, edit the BPXPRMxx member that will be used for IPLs.

MAXTHREADS(nnnnnn)

Specifies the maximum number of pthread_created threads, including running, queued, and exited but undetached, that a single process can have concurrently active. Specifying a value of 0 prevents applications from using pthread_create.

Value range: nnnnnn is a decimal value from 0 to 100000.

Default: 200

You can change the value of MAXTHREADS dynamically using the SETOMVS or SET OMVS command. To make a permanent change, edit the BPXPRMxx member that will be used for IPLs.

For planning information, see MAXTHREADS in z/OS UNIX System Services Planning.

MAXTHREADTASKS(nnnnn)

Specifies the maximum number of MVS tasks that a single process can have concurrently active for pthread_created threads.

Value range: nnnnn is a decimal value from 0 to 32768.

Default: 1000

You can change the value of MAXTHREADTASKS dynamically using the SETOMVS or SET OMVS command. To make a permanent change, edit the BPXPRMxx member that is used for IPLs.

For planning information, see MAXTHREADTASKS in z/OS UNIX System Services Planning.

MAXUIDS(nnnnn)

Specifies the maximum number of z/OS UNIX user IDs (UIDs) that can operate concurrently.

Value range: nnnnn is a decimal value from 1 to 32767.

Default: 200

Use the SETOMVS or SET OMVS command to dynamically increase or decrease the value of MAXUIDS. To make a permanent change, edit the BPXPRMxx member that will be used for IPLs.

For planning information, see the section on MAXUIDS in z/OS UNIX System Services Planning.

MAXUSERMOUNTSYS(nnnn)

Specifies the maximum number of nonprivileged user mounts for the system or for the shared file system configuration environment. The MAXUSERMOUNTSYS limit applies only to nonprivileged users and does not affect privileged mounts.

Value range: nnnnn is a decimal value from 0 to 35000 that indicates the maximum number of nonprivileged user mounts allowed in the system. For those using a shared file system configuration, this value is the maximum number of nonprivileged user mounts allowed in the shared file system environment. The most recent specification prevails for all of the systems that are participating in a shared file configuration.

Default: 0

Use the SETOMVS or SET OMVS command to dynamically increase or decrease the value of MAXUSERMOUNTSYS. To make a permanent change, edit the BPXPRMxx member that is used for IPLs. If MAXUSERMOUNTSYS is not specified, default values are used. The default value indicates that user mounts are not allowed in the system.

For planning information, see MAXUSERMOUNTSYS in z/OS UNIX System Services Planning.

MAXUSERMOUNTUSER(nnnn)

Specifies the maximum number of nonprivileged user mounts allowed for each nonprivileged user.

Default: For a single system, the default value is 0. For the first IPLed system in the shared file system configuration, the default value is 0. For a subsequently IPLed system in the shared file system configuration, the default value is what other systems have at the time when the subsequent system is IPLed.

For planning information a list of restrictions, see MAXUSERMOUNTUSER in z/OS UNIX System Services Planning.

MOUNT FILESYSTEM('fsname') DDNAME(ddname) TYPE(type_name) MOUNTPOINT('pathname') MODE(access) PARM('parameter') TAG(NOTEXT|TEXT,ccsid) SETUID|NOSETUID SECURITY|NOSECURITY AUTOMOVE[(INCLUDE,sysname1,sysname2,...,sysnamen|*)] [(EXCLUDE,sysname1,sysname2,...,sysnamen)]

|NOAUTOMOVE|UNMOUNT SYSNAME(sysname) MKDIR('pathname')

Specifies a file system that z/OS UNIX is to logically mount onto the root file system or another file system.

Mount statements are processed in the sequence in which they appear. If they are cascading, the system mounts the first file system first. Make sure that a mount point exists before the file system is mounted. If you mount a file system over an existing directory that contains files, you will cover up the existing files.

If a MOUNT statement uses a DDNAME parameter to identify the HFS data set, allocate that HFS data set in the OMVS cataloged procedure. See the section on customizing the OMVS cataloged procedure to run the kernel initialization program in z/OS UNIX System Services Planning.

The MOUNT statement is optional; the BPXPRMxx member can contain one or more MOUNT statements. The MOUNT parameters are:

AUTOMOVE[(INCLUDE|EXCLUDE,sysname1,sysname2,...,{sysnameN| *})]|

NOAUTOMOVE|UNMOUNT

The AUTOMOVE, NOAUTOMOVE, and UNMOUNT parameters apply only in a sysplex where systems are participating in shared file system. The parameters indicate what happens if the system that owns a file system goes down.

AUTOMOVE indicates that ownership of the file system automatically changes to another system that is participating in shared file system. You can specify AUTOMOVE on its own to allow the system to randomly select a new owner for the file system. You can direct the system how to choose a new owner for the file system by using the indicators INCLUDE (I) or EXCLUDE (E).

Specify INCLUDE with a system list to provide a prioritized list of systems to which the file system can be moved if the owning system goes down. For example, AUTOMOVE(INCLUDE,SYS1,SYS4,SYS9) tells the system that the file system can be moved to SYS1, SYS4, or SYS9, in that order, or AUTOMOVE(INCLUDE,SYS1,SYS4,*) tells the system that the file system can be moved to SYS1 or SYS4, in that order, then to any other available system. This selection is not totally random; rather, MVS attempts to move the file system to a new server system in which the file system is actively in use.

Restriction: If specified, the asterisk must be listed last or listed as the only system name in the INCLUDE system list.

Specify EXCLUDE with a system list to provide a list of systems to which the file system cannot be moved. For example, AUTOMOVE(EXCLUDE,SYS3,SYS5,SYS7) tells the system that the file system can be moved to any system except SYS3, SYS5, and SYS7. If the file system cannot be moved as you directed in the system list, the file system is unmounted when the owning system goes down.

NOAUTOMOVE indicates that ownership of the file system is not moved in some situations; as a result, the file system becomes inaccessible.

Note: When specifying NOAUTOMOVE, although the file system becomes inaccessible when the owning system unexpectedly goes down, it still exists in the file system hierarchy. The file system remains unowned until the original owning system re-IPLs. Changing the AUTOMOVE value in BPXPRMxx of an unowned file system before re-IPLing will not change the AUTOMOVE value of this file system since it is already mounted. To change the AUTOMOVE value, the file system must be unmounted before the IPL.

UNMOUNT indicates that the file system should be unmounted in certain situations.

See z/OS UNIX System Services Planning for more information about the behavior of the AUTOMOVE options.

Note:

Use AUTOMOVE for the version file system and the sysplex root file system.
For file systems that are associated with a single system, specify UNMOUNT. The file systems include /etc,/tmp, /var, /dev, and the system-specific file system. For descriptions of the sysplex root, system-specific, and version file systems, see the section on sharing file systems in a sysplex in z/OS UNIX System Services Planning.
For sysplex-unaware file systems that are mostly exported by the DFS or SMB server to their remote clients, consider specifying NOAUTOMOVE on the MOUNT statement. By doing so, the file systems will not change ownership if the system is suddenly recycled and they are available for automatic re-export by DFS or SMB.
Consider specifying NOAUTOMOVE because a file system can only be exported by the DFS or SMB server at the system that owns the file system. After a file system is exported by DFS, it cannot be moved until it has been unexported by DFS. The same holds true of file systems that are exported by SMB. When recovering from system outages, you need to weigh sysplex availability against availability to the DFS or SMB clients. When an owning system recycles and a file system that is exported by DFS or SMB is taken over by one of the other systems, DFS or SMB cannot automatically re-export that file system. When an owning system is recycled and an exported file system is taken over by one of the other systems, that file system is not automatically reexported. The file system must be moved from its current owner back to the original system, the one that has just been recycled, and then exported again.

Default: AUTOMOVE

DDNAME(ddname)

The ddname on the JCL DD statement that defines the file system. To use the DDNAME parameter, a DD statement for the HFS data set containing the mountable file system should be placed in the OMVS cataloged procedure. Either FILESYSTEM or DDNAME is required; do not specify both. The name is 1 to 8 characters; the system converts the ddname to uppercase.

Restriction: zFS does not support DDNAME; the FILESYSTEM keyword must be used.

FILESYSTEM('fsname')

The name of the file system. The name must be unique in the system.

In the FILESYSTYPE statement, you can mount the following file systems:

HFS for a hierarchical file system (HFS). See the section on managing hierarchical file system data sets in z/OS DFSMSdfp Advanced Services.
zFS for a z/OS File System (zFS). See the mount section in z/OS Distributed File Service zFS Administration.
NFS for accessing remote files. See the section on mount processing parameters in z/OS Network File System Guide and Reference.
TFS for a temporary file system (TFS). See the section on mounting the TFS in z/OS UNIX System Services Planning.

Either FILESYSTEM or DDNAME is required; do not specify both. The name is 1 to 44 characters; the characters can be in uppercase, lowercase, or both. The name must be enclosed in single quotation marks. An HFS data set name must conform to the rules of MVS data set names.

MKDIR('pathname')

Specifies the name of a directory that the system will create dynamically after the file system has been successfully mounted. This allows the system to create mount points that subsequent MOUNT statements can reference. MKDIR is an optional keyword.

You can specify more than one MKDIR keyword on each ROOT or MOUNT statement. The directories are created in the order they are listed. Currently, the maximum number of MKDIR statement that is allowed for each ROOT or MOUNT statement is 50.

You must specify a relative path name; the path name cannot start with a slash (/). Enclose the path name in single quotation marks.

The path name is relative to the file system mount point specified on the MOUNTPOINT keyword.

The path name can contain intermediate directories, but these intermediate directories must exist in the file system hierarchy. If these intermediate directories do not exist, you can use additional MKDIR keywords to create the necessary intermediate directories.

The directory to be created must be in a file system that was mounted as RDWR. The permission bits for the created directory will be 755. The UID and GID is inherited from this directory's parent. These attributes are overlaid when this directory is used as a mount point.

Do not use the MKDIR keyword for file systems that mount asynchronously, such as the NFS file system. When a file system is mounted asynchronously, message BPXF025I is issued to the system log. Similarly, do not use MKDIR with the SYSNAME keyword, when SYSNAME identifies a remote system to perform the mount. The results are unpredictable.

A failure to create a directory does not cause a failure of the mount. A message is written to the system log when a problem occurs during the creation of the directory. If the directory exists, no message is written.

MODE(access)

Specifies access to the mounted file system by all users:

READ: Users can only read the file system that is being mounted.
RDWR: Users can read and write in the file system that is being mounted.

Default: RDWR

MOUNTPOINT('pathname')

Specifies the absolute path name, or a symbolic link that resolves to the path name of the directory onto which the file system is to be mounted.

Mount point restrictions are as follows:

The mount point must be a directory.
Any files in the directory are not accessible while the file system is mounted.
Only one mount can be active at any time for a mount point.
A file system can be mounted at only one directory at any time.

MOUNTPOINT is required and must specify an absolute path name. The path name is up to 1023 characters long; the characters can be in uppercase, lowercase, or both.

PARM('parameter')

Provides a parameter to be passed directly to the file system type. The parameter format and content are specified by the file system type.

PARM is an optional parameter. The parameter is up to 500 characters long; the characters can be in uppercase, lowercase, or both. The parameter must be enclosed in single quotation marks.

Note: For information about specifying the TFS configuration parameters, see the section on parameter key options for the mount statement and mount command in z/OS UNIX System Services Planning. For example:

-ea count: Allows the TFS file system to automatically grow count times.
-em count: Allows the TFS file system to manually grow count times.

If the physical file system specified does not expect a PARM operand, it ignores all PARM operands. Refer to the documentation for the specific physical file system for valid entry point names.

SYNC(t), NOWRITEPROTECT, NOSPARSE, and SYNCRESERVE are valid only when ENTRYPOINT is GFUAINIT. FSFULL(threshold,increment) is supported by HFS, TFS, and z/OS File System (zFS).

Note: If a syntax error is found in any of these parameters (SYNC(t), NOWRITEPROTECT, NOSPARSE, FSFULL, and SYNCRESERVE), an error message is issued and all five parameters are set to the default values.

SYNC(t)
- t specifies the number of seconds used as a default for the sync daemon interval. When the sync daemon is active, the metadata for a file system is hardened. Setting t to 0 indicates that the file system should harden metadata synchronously with syscall requests.
- Sync interval values are rounded up to the next 30-second value. For example, specifying 31 seconds results in a sync interval of 60 seconds.
- The maximum value that can be specified for t is 65535. Values between 65535 and 99999 are rejected.
- A value of 99999 specifies that no sync daemon intervals are specified, and thus, the metadata is not hardened.
- The default is 60 seconds.
NOWRITEPROTECT
- This keyword overrides the WRITEPROTECT function. When NOWRITEPROTECT is specified, the file system is not protected from being read/write mounted by multiple systems simultaneously. Read/write mounting by multiple systems corrupts the file system.
  Extreme care should be taken when specifying this keyword. It should only be used when there is no possibility of the file system that is being mounted by multiple systems.
  
  Use of the NOWRITEPROTECT keyword avoids an additional file system read operation that is required at Sync time to support the WRITEPROTECT function.
Default: WRITEPROTECT
NOSPARSE (DUMP|LOGREC)
- When NOSPARSE is specified on the MOUNT statement, HFS will not allow any files in that file system to be sparse. A file becomes sparse when all of the data cannot be written. For example, suppose we are only able to write the first 10,000 bytes of a file, and then the system has to lseek out to offset 50,000 and resume writing from there. The file is considered sparse because bytes 10,000-50,000 were never written to the file. If the user attempts to read bytes 10,000 to 50,000, binary zeros are returned as the value. NOSPARSE handles this by causing a dump to be taken or LOGREC record to be created when either of the following situations occur:
  - The file system attempts to read metadata from disk for a file and detects that the subject file is sparse, or
  - An application attempts to write to a page beyond the end of the file, causing the file to become sparse.
- DUMP causes a dump to be created. Only one dump is created for each of the possible reason codes while a file system is mounted. DUMP is the default if you specify NOSPARSE without the DUMP or LOGREC keywords.
- LOGREC causes a LOGREC record to be written. A dump is not created.
Default: DUMP
FSFULL(threshold,increment)
- threshold specifies the percentage of the file system (HFS, TFS, or zFS) capacity at which an operator message is generated. The default is 100%.
- increment specifies the percentage of change above the HFS or zFS capacity at which an operator message is generated. Messages are generated by either an increase or decrease greater than increment. The default is 5%.
  You can specify threshold and increment values for all file systems. The values can also be set on the MOUNT command for a specific file system. Parameters on the MOUNT command override parmlib values. If no values are specified in either place, no threshold checking is done. If a threshold value is specified but no increment is given, the increment defaults to 5%. The increment value applies both to upgrading the message when the file system continues to fill and to removing the message when more space becomes available due to either deleting files, or to extending the file system. The values are in terms of percent full. The values that are applied to a file system can be changed only when the file system is mounted.
RNODEWAIT(t)
- t specifies the number of seconds for threads to wait for file in use serialization before timing out. Valid values are 1-1500.
  Default: 1500
WAITABEND
- If WAITABEND is specified, the file in use serialization time out causes a dump to be taken for diagnostic purposes. The EBUSY signal from the time out is returned.
  Default: 1500
SYNCRESERVE(nn)
- This keyword controls the number of pages to be reserved for sync processing of the file system metadata.nn represents the percentage of the file system space that is to be reserved for the sync shadow write mechanism. nn is a decimal number between 1 and 50. There is no reason to reserve more than 50% of the file system space, because the reserved space must always be less than the actual index size and the index size plus the reserved space cannot be greater than the file system space.
- When this parameter is specified on the MOUNT statement, it overrides the internal reserved page estimation algorithm. Only use this parameter if the internal algorithm is not providing the desired results.

SYSNAME(sysname)

For systems that are participating in a shared file system, SYSNAME specifies the particular system on which a mount should be performed. This system will then become the owner of the file system mounted. This system must be IPLed with SYSPLEX(YES).

Default: The name of the system, if IPLed with SYSPLEX(YES), that the mount is processed on.

Notes:

Use the defaults for SYSNAME and AUTOMOVE to ensure that the root is always available.
Only specify a SYSNAME() value if you want only the specified system to be the file system owner.
During z/OS UNIX initialization processing, the MOUNT statement is ignored if SYSNAME() specifies another system.
For SET OMVS and SETOMVS processing, the MOUNT statement is processed and the MOUNT is function-shipped to the system specified by SYSNAME(). If SYSNAME() is used with a value that resolves to another system, do not include any subsequent parmlib MOUNT statements that specify a MOUNTPOINT() with a path name that includes a directory in this file system.

TAG (NOTEXT|TEXT,ccsid)

Specifies whether implicit file tags are assigned to untagged files in the mounted file system. File tagging controls whether a file's data can be converted during file reading and writing. "Implicit" in this case means that the tag is not permanently stored with the file. Instead, the tag is associated with the file during reading and writing, or when stat() type functions are issued. Either TEXT, or NOTEXT, and ccsid must be specified when TAG is specified.

NOTEXT specifies that none of the files in the file system are automatically converted during file reading and writing.

TEXT specifies that each untagged file is implicitly marked as containing pure text data that can be converted.

ccsid names the coded character set identifier to be implicitly set for the untagged file. ccsid is specified as a decimal value from 0 to 65536. However, when TEXT is specified, the values of 0 and 65536 are not allowed because those values imply no conversion. Other than this, the value is not checked as being valid and the corresponding code page is not checked as being installed.

For example:

TAG(TEXT,819) identifies text files that contain ASCII (ISO-8859-1) data.
TAG(TEXT,1047) identifies text files that contain EBCDIC ((ISO-1047) data.
TAG(NOTEXT,65536) tags files as containing binary or unknown data.
TAG(NOTEXT,0) is the equivalent of not specifying the TAG parameter.
TAG(NOTEXT,273) tags file with the German code set (ISO-273) but is not eligible for automatic conversion.

Default: NOTEXT

SECURITY|NOSECURITY

SECURITY specifies that security checks should be performed. NOSECURITY specifies that security checks should not be performed.

Default: SECURITY

SETUID|NOSETUID

SETUID specifies that the setuid() and setgid() mode bit on an executable file will be supported.

NOSETUID specifies that the setuid() and setgid() mode bit on an executable file will not be supported. The UID or GID will not be changed when the program is executed and the APF and Program Control extended attributes are not honored. The entire HFS is uncontrolled.

Default: SETUID

TYPE(type_name)

Specifies the name of a file system type that is identified in a FILESYSTYPE statement. The TYPE(type_name) parameter must be the same as the TYPE(type_name) parameter on a FILESYSTYPE statement. TYPE is a required parameter. The name is 1 to 8 characters; the system converts the name to uppercase.

For additional information, see the MOUNT section in z/OS UNIX System Services Planning.

NETWORK DOMAINNAME(sockets_domain_name) DOMAINNUMBER(sockets_domain_number) MAXSOCKETS(number) TYPE(type_name) INADDRANYPORT(starting_port_number) INADDRANYCOUNT(number_of_ports_to_reserve)

Specifies that a socket physical file system domain should be readied for use. The TYPE in this statement matches the TYPE on the previous FILESYSTYPE statement.

Use the SETOMVS RESET command to dynamically change the MAXSOCKET value or add a new NETWORK. To make a permanent change, edit the BPXPRMxx member that is used for IPLs. For more information, see the section on dynamically adding FILESYSTYPE statements in BPXPRMxx in z/OS UNIX System Services Planning.

Provide a NETWORK statement for each socket file system domain to be initialized.

For AF_UNIX file systems, always include a FILESYSTYPE statement that specifies ENTRYPOINT(BPXTUINT) and a NETWORK statement with a matching TYPE, usually TYPE(UDS), on both.
For TCP/IP sockets, always include a FILESYSTYPE statement that specifies ENTRYPOINT(EZBPFINI) and a NETWORK statement with a matching TYPE, usually TYPE(INET), on both.
To activate an Internet Protocol Version 6 (IPv6) socket on a system, you must configure both the AF_INET domain and the AF_INET6 domain. You cannot code a NETWORK statement for domain name AF_INET6 without coding a NETWORK statement for domain name AF_INET.
For CINET sockets, include a FILESYSTYPE statement with ENTRYPOINT (BPXTCINT) and a NETWORK statement with a matching TYPE, usually TYPE(CINET), that specifies INADDRANYPORT and INADDRANYCOUNT. See the section on specifying INADDRANYPORT and INADDRANYCOUNT in z/OS UNIX System Services Planning for more information.

DOMAINNAME(sockets_domain_name)

The 1 - 16 character name by which this socket file system domain is to be known.

DOMAINNUMBER(sockets_domain_number)

A number that matches the value that is defined for this domain name. The currently supported values for this field are:

1: AF_UNIX
2: AF_INET
19: AF_INET6

Table 1 shows some supported domain names, domain numbers, and their associated entry point names. See the documentation for the physical file system you are using to get the correct entry point name.

Table 1. Supported domains
Domain name	Domain number	Entry point
AF_UNIX	1	BPXTUINT
AF_INET	2	EZBPFINI, BPXTCINT
AF_INET6	19	EZBPFINI, BPXTCINT

INADDRANYCOUNT(number_of_ports_to_reserve)

Specifies the number of ports that the system reserves, starting with the port number specified in the INADDRANYPORT parameter. This value is only needed for CINET.

Value range: number_of_ports_to_reserve is a decimal value from 1 to 8000.

If neither INADDRANYPORT or INADDRANYCOUNT is specified, the default for INADDRANYCOUNT is 1000. Otherwise, no ports are reserved (0).

INADDRANYPORT(starting_port_number)

Specifies the starting port number for the range of port numbers that the system reserves for use with PORT 0, INADDR_ANY binds. This value is only needed for CINET.

Value range: starting_port_number is a decimal value from 1024 to 65534. Ports 1 — 1023 are well-known ports that cannot be reserved for use with PORT 0, INADDR_ANY binds.

If neither INADDRANYPORT or INADDRANYCOUNT is specified, the default for INADDRANYPORT is 63000. Otherwise, no ports are reserved (0).

Note: If you do not want to support INADDRANY with CINET, you should specify INADDRANYPORT(xx), where xx is a valid value, without specifying INADDRANYCOUNT.

Note: When activating IPv6 on a system, the INADDRANYPORT is shared across domains. The INADDRANYPORT value is taken from the NETWORK statement for the AF_INET domain. Any INADDRANYPORT value that is specified for the AF_INET6 domain is ignored.

MAXSOCKETS(nnnnn)

Specifies the maximum number of sockets that are supported by this file system for this address family. You can specify a value from 0 to 16777215. This is an optional parameter. The maximum value that this field can have is defined by each domain. If a value larger than the maximum is specified, an informational message is issued and the value used is the maximum.

Note: Ensure that this number is large enough for socket connections for all applications using your z/OS UNIX environment. This upper limit is set when the NETWORK statement is processed during IPL. It can only be changed if the NETWORK statement is changed using the SETOMVS RESET command.

When the Common Event Adapter (CEA) is active, each CEA client requires two socket connections for communication with the CEA server.

For AF_UNIX, MAXSOCKETS will be ignored if it is specified. The maximum number of AF_UNIX sockets is 10000.

When activating IPv6 on a system, you can specify separate MAXSOCKETS values for domains AF_INET and AF_INET6. If you do not specify a MAXSOCKETS value for the AF_INET6 domain, the default will be the MAXSOCKETS value specified or defaulted to for the AF_INET domain.

Table 2 shows the maximum and default values for MAXSOCKETS by domain.

Table 2. Maximum and default values for MAXSOCKETS by domain
Domain name	MAXSOCKETS maximum	MAXSOCKETS default
AF_UNIX	10000	10000
AF_INET	16777215	64000
AF_INET6	16777215	Same as the current value for AF_INET

TYPE(type_name)

Specifies the name of a file system type that is identified in a FILESYSTYPE statement. The TYPE(type_name) must be the same as the TYPE(type_name) parameter on a FILESYSTYPE statement. TYPE is a required parameter. The name is 1 to 8 characters; the system converts the name to uppercase.

NONEMPTYMOUNTPT(NOWARN|WARN|DENY)

Specifies how the system is to mount any file system on a mount point when it is a non-empty directory.

NOWARN causes the system to mount any file system on mount point without any warning message when the mount point is a non-empty directory. The contents of that directory are hidden for the duration of the mount.

WARN causes the system to mount any file system on mount point with a warning message when the mount point is a non-empty directory. The contents of that directory are hidden during the mount.

DENY causes the system not to mount any file system when the mount point is a non-empty directory.

Note: NOWARN

If NONEMPTYMOUNTPT is not specified, default values are used.

For planning information, see NONEMTPYMOUNTPT in z/OS UNIX System Services Planning.

PRIORITYGOAL(service_class_name1,...service_class_name40)

Specifies a list of 1 to 40 service class names of 8 characters or less separated by commas, which are used in association with the setpriority, nice and chpriority callable services when the system is running in goal mode. These functions allow a program to alter the priority of one or more processes.

Generally, it is recommended that you not set PRIORITYGOAL unless the nice(), setpriority() or chpriority() values is enabled.

If the list has less than 40 entries, the system propagates the last service class specified into the remaining unspecified entries in the table. For example:

  PRIORITYGOAL(CICS4,CICS4,CICS4,CICS3,CICS2,CICS1,TSO2,TSO1,BAT3,BAT2)

If you do not specify this statement, arrays are not created for it. All service classes that are specified on the PRIORITYGOAL statement must also be specified in your workload manager service policy.

PRIORITYGOAL(NONE) means that there are no values. If you do not specify PRIORITYGOAL, that means that there are no values.

If you do not want to allow users to increase the priority but still want to enable the nice() and setpriority() functions, define a range of service classes with priority increments on a base that is normal for the users. Using these functions lets the user order the priority of processes, but will not let a user improve performance over that of other users.

Value range: service_class_name is a 1 - 8 character value.

There is no default.

You can dynamically change the values of PRIORITYGOAL by using the SETOMVS or SET OMVS command. To make a permanent change, edit the BPXPRMxx member that is used for IPLs.

PWT(SMF|SMFENV|ENV)

Allows installations to time out z/OS UNIX processes that are waiting on terminal activity. When specified, the timeout value applies to all z/OS UNIX processes that are waiting on terminal activity. To override that value for a specific process, the _BPXK_TIMEOUT environment value can be set for an individual process. The PWT value can be changed with the SETOMVS PWT operator command. Unless a BPXK_TIMEOUT value is set, timeouts do not occur.

ENV: Allows the _BPXK_TIMEOUT variable be set. Only processes setting the _BPXK_TIMEOUT value are timed out.
SMF: Honors the SMPFPRMxx JWT|TWT|SWT values for the timeout value. The _BPXK_TIMEOUT environment value is ignored. An individual process cannot override the system settings.
SMFENV: Honors the SMFPRMxx JWT|TWT|SWT value and to allow the _BPXK_TIMEOUT settings to override the setting.

Note: ENV

RESOLVER_PROC(procname|DEFAULT|NONE)

Specifies how the resolver address space is processed during z/OS UNIX initialization. The resolver is used by TCP/IP applications for name-to-address or address-to-name resolution. In order to create a resolver address space, a system must be configured with an AF_INET or AF_INET6 domain.

DEFAULT: Causes an address space named RESOLVER to start, using the system default procedure of IEESYSAS. The address space is started with SUB=MSTR so that it runs under the MASTER address space instead of the JES address space.
NONE: Specifies that no address space is to be started. If you are using z/OS Communications Server IP, the resolver must be started before TCP/IP can be started. TCP/IP does not initialize until the resolver address space is started.
procname: The name of the address space for the resolver and the procedure member name in the appropriate proclib. procname is one to eight characters long. The procedure must reside in a data set that is specified by the MSTJCLxx parmlib member's IEFPDSI DD card specification.

RUNOPTS('string')

Specifies the _CEE_RUNOPTS environment variable that is used when z/OS UNIX initialization invokes /etc/init or /usr/sbin/init. z/OS UNIX passes the _CEE_RUNOPTS value and all programs that are invoked from /etc/rc to the shell.

If you want to change the value of RUNOPTS, you must edit the BPXPRMxx member and then re-IPL. You cannot use the SET OMVS or SETOMVS command to change the value. After the value is specified in BPXPRMxx, you can use one of the following methods to change this string:

The system is re-IPLed with a new BPXPRMxx RUNOPTS string.
The user or installation sets _CEE_RUNOPTS in /etc/rc or /etc/init.config.
A program or shell script sets _CEE_RUNOPTS.

If you do not specify a value for RUNOPTS, the RUNOPTS string or _CEE_RUNOPTS environment variable is not provided.

The TSO/E OMVS command uses the specified options as the Language Environment® runtime options, by default.

The setting of RUNOPTS has no effect on BPXBATCH jobs.

Specifying the RUNOPTS parameter causes the kernel to set the _CEE_RUNOPTS environment variable when starting /etc/init, or when the TSO/E OMVS command is entered. This environment variable is normally propagated to subsequent processes (such as /etc/init to /bin/sh to /etc/rc to /bin/inetd to /bin/rlogind to /bin/sh for shell users).

To do this, you must make sure that any other steps in the flow (such as export statements in /etc/rc) do not overwrite the value of _CEE_RUNOPTS. If more runtime options are needed, they should be concatenated to the old value of _CEE_RUNOPTS.

Value range: From 1 to 250 characters.

Default: No RUNOPTS string or _CEE_RUNOPTS environment variable is provided.

Restrictions:

The string must be enclosed in parentheses and quotation marks ('').
An empty string (' ') is not valid.
Although all characters are allowed, nulls, slashes (/), unbalanced SO/SI, and unbalanced parentheses and quotation marks cause unpredictable problems in areas such as the TSO/E OMVS command.

For more information about specifying RUNOPTS strings, see Customizing the BPXPRMxx member of SYS1.PARMLIB in z/OS UNIX System Services Planning.

ROOT FILESYSTEM('fsname') DDNAME(ddname) TYPE(type_name) MODE(access) PARM('parameter') SETUID|NOSETUID SECURITY|NOSECURITY AUTOMOVE|NOAUTOMOVE SYSNAME(sysname) TAG(NOTEXT|TEXT,ccsid) MKDIR('pathname')

Specifies a file system that z/OS UNIX is to logically mount as the root file system. It is optional. If it is not specified, a TFS file system is mounted as the root.

To change the value of the ROOT statement without having to re-IPL, use the TSO/E MOUNT and UNMOUNT commands.

The root file system can be unmounted using the TSO/E UNMOUNT command or ISHELL. Ensure that you specify the IMMEDIATE option.

The ROOT statement does not support the SYSNAME() keyword.

The parameters are as follows:

DDNAME(ddname)

The ddname on the JCL DD statement that defines the root file system. To use the DDNAME parameter, a DD statement for the HFS data set containing the root file system should be placed in the z/OS UNIX cataloged procedure.

Either FILESYSTEM or DDNAME is required; do not specify both. The ddname is 1 to 8 characters; the system converts the ddname to uppercase.

Restriction: zFS does not support DDNAME; the FILESYSTEM keyword must be used.

FILESYSTEM('fsname')

The name of the root file system. The name must be unique in the system.

You can specify the following types of the file system:

HFS for a hierarchical file system (HFS).
zFS for a z/OS File System (zFS).
NFS for accessing remote files.
TFS for a temporary file system (TFS).

Either FILESYSTEM or DDNAME is required; do not specify both. The name is 1 - 44 characters; the characters can be in uppercase, lowercase, or both. The name must be enclosed in single quotation marks. An HFS data set name must conform to the rules of MVS data set names.

MKDIR('pathname')

Specifies the name of a directory that the system will create dynamically after the file system is successfully mounted. This allows the system to create mount points that can be referenced by subsequent MOUNT statements. MKDIR is an optional keyword.

You can specify more than one MKDIR keyword on each ROOT statement. The directories are created in the order they are listed.

You must specify a relative path name; the path name cannot start with a slash (/). Enclose the path name in single quotation marks.

The path name is relative to the file system mount point specified on the MOUNTPOINT keyword.

The directory to be created must reside in a file system that was mounted as RDWR. The permission bits for the created directory is 755. The UID and GID is inherited from this directory's parent. These attributes are overlaid when this directory is used as a mount point.

Do not use the MKDIR keyword for file systems that mount asynchronously, such as the NFS file system. When a file system is mounted asynchronously, message BPXF025I is issued to the system log. Also, do not use MKDIR with the SYSNAME keyword, when SYSNAME identifies a remote system to perform the mount. The results are unpredictable.

A failure to create a directory does not cause a failure of the mount. A message is written to the system log when a problem occurs when the directory is created. If the directory exists, no message is written.

Restriction: MKDIR works only on systems that are at z/OS Version 1 Release 5 level or later. If you are using MKDIR in a sysplex that shares a common BPXPRMxx member, make sure that all systems are at least at the z/OS V1R5 level.

MODE(access)

Specifies access to the root file system by all users:

READ: Users can only read the root file system.
RDWR: Users can read and write in the root file system.

Note: RDWR

PARM('parameter')

Provides a parameter to be passed directly to the file system type. The parameter format and content are specified by the file system type.

PARM is an optional parameter. The parameter is up to 500 characters long; the characters can be in uppercase, lowercase, or both. The parameter must be enclosed in single quotation marks.

If the physical file system specified does not expect a PARM operand, it ignores all PARM operands. Refer to the documentation for the specific physical file system for valid entry point names.

SYNC(t), NOWRITEPROTECT, NOSPARSE, and SYNCRESERVE are valid only when ENTRYPOINT is GFUAINIT. FSFULL(threshold,increment) is supported by HFS and TFS.

Note: If a syntax error is found in any of these parameters (SYNC(t, NOWRITEPROTECT, NOSPARSE, FSFULL, and SYNCRESERVE), an error message is issued and all five parameters are set to the default values.

SYNC(t)
- t specifies the number of seconds used as a default for the sync daemon interval. When the sync daemon is active, the metadata for a file system is hardened. Setting t to 0 indicates that the file system should harden metadata synchronously with syscall requests.
- Sync interval values are rounded up to the next 30-second value. For example, specifying 31 seconds results in a sync interval of 60 seconds.
- The maximum value that can be specified for t is 65535. Values between 65535 and 99999 are rejected.
- A value of 99999 specifies that no sync daemon intervals are specified, and thus, the metadata is not hardened.
- The default is 60 seconds.
NOWRITEPROTECT
- This keyword overrides the WRITEPROTECT function. When NOWRITEPROTECT is specified, the file system is not protected from being read/write mounted by multiple systems simultaneously. Read/write mounting by multiple systems corrupts the file system.
  Extreme care should be taken when specifying this keyword. Use it only when there is no possibility of the file system being mounted by multiple systems.
  
  Use of the NOWRITEPROTECT keyword avoids an additional file system read operation that is required at Sync time to support the WRITEPROTECT function.
- WRITEPROTECT is the default.
NOSPARSE(DUMP|LOGREC)
- When NOSPARSE is specified on the MOUNT statement, files are not allow to be sparse. A file becomes sparse when all of the data cannot be written. For example, suppose we are only able to write the first 10,000 bytes of a file, and then the system has to lseek out to offset 50,000 and resume writing from there. The file is considered sparse because bytes 10,000-50,000 were never written to the file. If the user attempts to read bytes 10,000 to 50,000, binary 0’s are returned as the value. NOSPARSE handles this by causing the file system to create a dump or a LOGREC record when either of the following situations occur:
  - The file system attempts to read metadata from disk for a file and detects that the subject file is sparse.
  - An application attempts to write to a page beyond the end of the file, causing the file to become sparse.
- DUMP causes the file system to create a dump. Only one dump is created for each of the possible reason codes while a file system is mounted. DUMP is the default if you specify NOSPARSE without the DUMP or LOGREC keywords.
- LOGREC will cause the file system to write a LOGREC record instead of creating a dump.
- DUMP is the default.
FSFULL(threshold,increment)
- threshold specifies the percentage of the file system (HFS or TFS) capacity at which an operator message is generated. The default is 100%.
- increment specifies the percentage of change above the file system capacity at which an operator message is generated. Messages are generated by either an increase or decrease greater than increment. The default is 5%.
  You can specify threshold and increment values for all file systems. The values can also be set on the MOUNT command for a specific file system. Parameters on the MOUNT command override parmlib values. If no values are specified in either place, no threshold checking is done. If a threshold value is specified but no increment is given, the increment defaults to 5%. The increment value applies both to upgrading the message when the file system continues to fill and to removing the message when more space becomes available due to either deleting files, or to extending the file system. The values are in terms of percent full. The values that are applied to a file system can be changed only when the file system is mounted.
SYNCRESERVE(nn)
- This keyword controls the number of pages to be reserved for sync processing of the file system metadata.nn represents the percentage of the file system space which is to be reserved for the sync shadow write mechanism. nn is a decimal number between 1 and 50. There is no reason to ever reserve more than 50% of the file system space, because the reserved space must always be less than the actual index size and the index size plus the reserved space cannot be greater than the file system space.
- When this parameter is specified on the MOUNT statement, it overrides the internal reserved page estimation algorithm. Only use it if the internal algorithm does not provide the expected results.

SCEXITTABLE('sc_exittable')

Specifies the path name of a z/OS UNIX file. This file is intended to contain a list of z/OS UNIX syscall stubs that a user wants to enable syscall exits for. The stub names must be in all caps. If a null path name is specified, SC_EXITTABLE is reset to null.

You can change the SC_EXITTABLE path name dynamically by using the SETOMVS or SET OMVS command. To make a permanent change, edit the BPXPRMxx member that will be used for IPLs.

Changes to the SC_EXITTABLE file are not applied immediately. If a change needs to be activated sooner, use the SETOMVS or SET OMVS command to apply the change immediately.

SERV_LINKLIB('dsname','volser')

Specifies the target service library where the z/OS UNIX modules that are normally loaded from SYS1.LINKLIB into the private area of the OMVS address space are located.

If a null dsname is specified, SERV_LPALIB is reset to null. It doe not matter what is specified for volser if dsname is null.

Value range: dsname is a 1-to-44 character value that represents a valid MVS load library data set name. The alphabetic characters in the load library name must be uppercase. volser is a 1-to-6 character value that represents a valid volume serial number for the volume that contains the specified MVS load library. The alphabetic characters in the volume serial number must be uppercase.

You can change the value of SERV_LINKLIB dynamically using the SETOMVS or SET OMVS command. To make a permanent change, edit the BPXPRMxx member that will be used for future IPLs.

SERV_LPALIB('dsname','volser')

Specifies the target service library where the z/OS UNIX modules that are normally built into LPA are located.

Note: dsname is a 1-to-44 character value that represents a valid MVS load library data set name. The alphabetic characters in the load library name must be uppercase. volser is a 1-to-6 character value that represents a valid volume serial number for the volume that contains the specified MVS load library. The alphabetic characters in the volume serial number must be uppercase.

You can change the value of SERV_LPALIB dynamically using the SETOMVS or SET OMVS command. To make a permanent change, edit the BPXPRMxx member that will be used for future IPLs.

If a null dsname is specified, SERV_LNKLIB is reset to null. It doe not matter what is specified for volser if dsname is null.

SECURITY|NOSECURITY

SECURITY: Security checks are performed. SECURITY is the default.
NOSECURITY: Security checks are not performed.

SETUID|NOSETUID

SETUID: Specifies that the setuid() and setgid() mode bit on an executable file will be supported.
NOSETUID: Specifies that the setuid() and setgid() mode bit on an executable file will not be supported. The UID or GID will not be changed when the program is executed and the APF and program control extended attributes are not honored. The entire file system is uncontrolled.

Default: SETUID

SHRLIBMAXPAGES(nnnnn)

If you specify the SHRLIBMAXPAGES parameter, it is accepted but will not have any impact on the system. The value that you specify will never be reached, because user-shared library objects are no longer supported. This parameter is intended to control the maximum number of pages that can be allocated in the system to contain user shared library modules. This value, used with MAXSHAREPAGES, can be used to control the amount of ESQA consumed by user shared library modules. Refer to z/OS UNIX System Services Planning for more details.

Value range: nnnnn is a decimal value between 1 and 16777216 specifying a number of 4 K pages.

Default: 4096

SHRLIBRGNSIZE(nnnnn)

Specifies the maximum size of the shared library region for address spaces that load system shared library modules. For these address spaces, the size that is specified is allocated from high private storage and is used for the loading of system shared library modules. This storage is not allocated in an address space until it loads a system shared library module. This parameter applies to modules loaded from system shared libraries, which allocate storage on megabyte boundaries. Therefore, this storage does not count against the MAXSHAREPAGES limit, and does not consume ESQA.

Value range: nnnnn is a decimal value between 16777216 (16 megabytes) and 1610612736 (1.5 gigabytes). The specified value (if within the range) is rounded up to a megabyte boundary.

Default: 67108864

Use the SETOMVS or SET OMVS command to dynamically increase or decrease the SHRLIBRGNSIZE value. To make a permanent change, edit the BPXPRMxx member that is used for IPLs.

Because the shared library region is allocated in megabytes, the value for SHRLIBRGNSIZE must be evenly divisible by 1048576. Otherwise, the D OMVS,L command might show values in the Current® Usage and Highwater Usage columns that are larger than the value in the System Limit column.

STARTUP_EXEC

STARTUP_EXEC names a REXX exec that does application environment initialization for z/OS UNIX. This statement is optional; if it is specified, the BPXOINIT process will not run /etc/init. The startup exec is typically used by an installation that does not have a file system, but is using a TFS for a file system. It can be used to populate the TFS with any directories and files that are needed. It is specified as:

STARTUP_EXEC('Dsname(Memname)',SysoutClass)

where:

Dsname is a 1-to-44-character valid data set name.
Memname is a 1-to-8-character valid REXX exec member.
SysoutClass is 1 character and is alphanumeric and specifies the sysout class that the REXX exec will run under. Specifying SysoutClass is optional.

If you want to change the value of STARTUP_EXEC, you will have to edit the BPXPRMxx member and then reIPL. You cannot use the SET OMVS or SETOMVS command to change the value.

There is no default value for STARTUP_EXEC.

STARTUP_PROC

This statement specifies a 1-to-8-character name of a started JCL procedure that initializes the kernel. The name specified in this statement must exist on the system before IPL or errors will occur.

Using a started procedure other than OMVS is strongly discouraged. If you want to change the value of STARTUP_PROC, you must edit the BPXPRMxx member and then re-IPL. You cannot use the SET OMVS or SETOMVS command to change the value.

If you decide to use a started procedure other than OMVS:

The replacement started procedure must also be a single job step procedure that invokes the BPXINIT program (EXEC PGM=BPXINIT). If it invokes any other program, the OMVS initialization will fail.
Change the procedure name in the RACF® started procedures table or the definitions in the STARTED Class. See Preparing for RACF in z/OS UNIX System Services Planning.

Note: Renaming OMVS to another value might affect the setup of other products such as TCP/IP.

Default: STARTUP_PROC(OMVS)

STEPLIBLIST

Specifies the path name of the file in the file system that contains the list of MVS data sets to be used as step libraries for programs that have the set-user-id and set-group-id bit set on.

For planning information, see STEPLIBLIST in z/OS UNIX System Services Planning.

SUBFILESYSTYPE NAME(transport_name) TYPE(type_name) ENTRYPOINT(entry_name) PARM('parameter') DEFAULT

Specifies an AF_INET or AF_INET6 physical file system that is to run underneath the CINET socket file system. The TYPE() value is usually CINET and matches the TYPE operand on a previous FILESYSTYPE and NETWORK statement. In the case of TCP/IP, the NAME() value is the procname. The system attaches the EZBPFINI load module during initialization, and this file system should be used as the default INET physical file system.

The SUBFILESYSTYPE statement is associated with its corresponding FILESYSTYPE and NETWORK statements by matching the value that is specified in the TYPE operand.

The value that is specified on all of the TYPE operands must match, but can be any 1- to 8-character value. The value that is specified on the NAME parameter on the SUBFILESYSTYPE statement is the name to be used by the physical file system when it is initialized. The first character of the NAME parameter must be non-numeric.

For SecureWay Communications Server, the SUBFILESYSTYPE statement must match the TCPIPJOBNAME of that stack. For more information about defining file systems, see the section on customizing the BPXPRMxx member in z/OS UNIX System Services Planning.

New SUBFILESYSTYPE statements can be added dynamically. However, you cannot dynamically change (or delete) a value. For more information, see the section on dynamically adding FILESYSTYPE statements in z/OS UNIX System Services Planning.

The parameters are as follows:

DEFAULT

Identifies this file system as the default CINET file system. DEFAULT is an optional parameter. If it is not specified, the file system that is specified in the first SUBFILESYSTYPE statement found in the parmlib member is designated as the default. See the section on setting up for CINET AF_INET sockets in z/OS UNIX System Services Planning for more information about the use of the DEFAULT parameter.

ENTRYPOINT(entry_name)

Specifies the name of the load module that contains the entry point into the file system type. ENTRYPOINT is a required parameter. The name is 1 to 8 characters; the system converts the name to uppercase.

NAME(transport_name)

Specifies the name that identifies this file system to the CINET physical file system.

NAME is a required parameter. The name is 1 to 8 characters with the first character non-numeric; the system converts the name to uppercase. The value that is specified by the NAME parameter on the SUBFILESYSTYPE statement is the name that the physical file system uses to identify itself when it is initialized. For example, for TCP/IP, this is the starting procedure name.

PARM('parameter')

Provides a parameter to be passed to the transport driver. The parameter format and content are specified by the file system that is receiving the data.

PARM is an optional parameter. The parameter is up to 1024 characters long; the characters can be in uppercase, lowercase, or both. If the characters are not all in uppercase, the parameter must be enclosed in single quotation marks.

If the physical file system specified does not expect a PARM operand, it ignores all PARM operands. Refer to the documentation for the specific physical file system for valid entry point names.

TYPE(type_name)

Specifies the name of the CINET file system type that is identified in a FILESYSTYPE statement. The TYPE(type_name) parameter must be the same name that was used for the TYPE(type_name) parameter on the FILESYSTYPE statement for the CINET physical file system. TYPE is a required parameter. The name is 1 to 8 characters; the system converts the name to uppercase.

For more information, see SUBFILESYSTYPE in z/OS UNIX System Services Planning.

SUPERUSER(user_name)

Superuser name, which must conform to the restrictions for the z/OS user ID. The user name must also be defined to RACF (or another security product) and must have a z/OS UNIX user ID (UID) of 0. For example, in RACF, specify OMVS(UID(0)) on the ADDUSER command.

When a daemon issues a setuid() to set a UID to 0 and the user ID is not known, setuid() uses the user ID from the SUPERUSER statement.

Never permit the user ID BPXROOT to the BPX.DAEMON profile (described in the section on setting up the BPX.* FACILITY class profiles in z/OS UNIX System Services Planning). This warning applies even if you use a name other than BPXROOT.

The USS_SUPERUSER health check verifies that the SUPERUSER option contains a user ID that is defined to the security product and has an OMVS segment with a UID of 0. For more information about the health check, see IBM Health Checker for z/OS User's Guide.

Value range: user_name is a 1 - 8 character value.

Default: BPXROOT

Use the SETOMVS or SET OMVS command to dynamically change the value of SUPERUSER. To make a permanent change, edit the BPXPRMxx member that is used for IPLs.

SWA(ABOVE|BELOW)

Specifies whether SWA control blocks should be allocated above or below the 16-megabyte line. The SWA parameter only affects the OMVS address space and its SWA blocks. It has no impact on the colony address spaces.

ABOVE: All SWA control blocks are to be allocated above the 16-megabyte line.
BELOW: All SWA control blocks are to be allocated below the 16-megabyte line.

Default: BELOW

SYSCALL_COUNTS(YES|NO)

Specifies that syscall counts are to be accumulated in internal kernel data areas so that the RMF data gatherer can record the information.

NO: The counts for syscall and CPU time are not accumulated.
YES: The path length for the most frequently used z/OS UNIX system calls is increased by more than 150 instructions. This setting will also cause the reporting of CPU time for z/OS UNIX to be more accurate. This is reflected in the output from the BPX1TIM, BPX1GPS, BPX1GTH, and BPX1RMG services and from BPXESMF.

If you switch between YES and NO for actively running processes, the accumulated data is inaccurate.

The SMF30OST field of the SMF type 30 record can be seen as a negative number when the CPU time used to compute the time value is less than the previous CPU time and in some cases can even appear as zero (for example, when SYSCALL_COUNTS is set to NO after having been YES for an earlier part of the run.) In addition, if SYSCALL_COUNTS=YES, the SMF30OST value is calculated from OCVTSYSTIME (accumulated syscall time for all syscalls issued in the system) rather than from OASBSYSCALLCOUNT (syscalls for the current process).

Default: NO

Use the SETOMVS or SET OMVS command to dynamically change the value of SYSCALL_COUNT. To make a permanent change, edit the BPXPRMxx member that is used for IPLs.

SYSPLEX(YES|NO)

For z/OS UNIX, the SYSPLEX statement specifies whether a system is to join the SYSBPX XCF group to share resources across the sysplex.

NO: The system does not participate in shared file system. If the SYSPLEX statement is not provided, the default is SYSPLEX(NO)
YES: The system participates in shared file system.

Default: NO

For more information about shared file systems, see Sharing file systems in a sysplex in z/OS UNIX System Services Planning. It contains information about parameters specific to shared file system: SYSPLEX, VERSION, AUTOMOVE, NOAUTOMOVE, and SYSNAME.

You cannot adjust the SYSPLEX field dynamically. There is no SETOMVS, SET OMVS, or SETOMVS RESET=(xx) capability. To change the value of SYSPLEX, you must re-IPL the system.

TAG (NOTEXT|TEXT,ccsid)

Specifies whether implicit file tags are assigned to untagged files in the mounted file system. File tagging controls whether a file's data can be converted during file reading and writing. “Implicit” in this case means that the tag is not permanently stored with the file. Instead, the tag is associated with the file during reading and writing, or when stat() type functions are issued. Either TEXT, or NOTEXT, and ccsid must be specified when TAG is specified.

ccsid: Names the coded character set identifier to be implicitly set for the untagged file. ccsid is specified as a decimal value from 0 to 65536. However, when TEXT is specified, the values of 0 and 65536 are not valid because those values imply no conversion. Other than this, the value is not checked as being valid and the corresponding code page is not checked as being installed.
NOTEXT: None of the files in the file system is automatically converted during file reading and writing.
TEXT: Each untagged file is implicitly marked as containing pure text data that can be converted.

For example:

TAG(TEXT,819) identifies text files that contain ASCII (ISO-8859-1) data.
TAG(TEXT,1047) identifies text files that contain EBCDIC ((ISO-1047) data.
TAG(NOTEXT,65536) tags files as containing binary or unknown data.
TAG(NOTEXT,0) is the equivalent of not specifying the TAG parameter.
TAG(NOTEXT,273) tags file with the German code set (ISO-273) but is not eligible for automatic conversion.

Default: NOTEXT

TYPE(type_name)

Specifies the name of a file system type that is identified in a FILESYSTYPE statement. The TYPE(type_name) parameter must be the same as the TYPE(type_name) parameter on a FILESYSTYPE statement.

TYPE is a required parameter. The name is 1 - 8 characters; the system converts the name to uppercase.

TTYGROUP(group_name)

Specifies the z/OS UNIX group name that is given to slave pseudoterminals (PTYs) and OCS remote terminals (RTYs). This group name must be defined to the security product and have a unique group ID (GID). No users should be connected to this group.

The group_name is used by certain setgid() programs, such as talk and write, when writing to another user's PTY or RTY.

Value range: group_name is a 1 - 8 character value.

Default: TTY

You can change the value of TTYGROUP dynamically using the SETOMVS or SET OMVS command. To make a permanent change, edit the BPXPRMxx member that will be used for future IPLs.

USERIDALIASTABLE('/etc/tablename')

Specifies the path name of a z/OS UNIX file. This file is intended to contain a list of z/OS UNIX user IDs and group names with their corresponding alias names. The alias names can contain any characters in the portable file name character set.

You can change USERIDALIASTABLE dynamically with the SETOMVS or SET OMVS command. To make a permanent change, edit the BPXPRMxx member that will be used for IPLs.

Once a user is logged into the system, changing the user ID or group name alias table does not change the alias name immediately. If a change needs to be activated sooner, you can use the SETOMVS or SET OMVS command to change the table more quickly.

For planning information, see USERIDALIASTABLE in z/OS UNIX System Services Planning.

UMASK(nnnn)

Specifies a default umask value for all z/OS UNIX users. Use this setting to better control the files and directories that users on your system can access. Existing facilities that set the umask value will continue to override the system default.

For example, the z/OS UNIX shell, /bin/sh, will first issue a umask call (BPX1UMK) to initially establish the process umask to 000. This will override the umask that is specified in BPXPRMxx. The shell will then process the /etc/profile file. If a umask command is specified, the specified value becomes the process umask value. If /etc/profile does not contain a umask command, the shell will keep the established umask of 000 as the process umask value.

Changing the default umask value might have unexpected results on your applications. A umask value that is consistent with the umask value that is set in /etc/profile might be appropriate.

Value range: nnnn is a 3-to-4 digit octal number that specifies the permission settings of files or directories created by users or processes that are not to be allowed.

nnnn can also be set to NONE to indicate that no system default umask was specified. NONE provides the capability to remove a prior umask specification for new processes. UMASK(NONE) differs from UMASK(000) in that specifying UMASK(NONE) causes OextUmaskConf to be reset, which indicates to applications such as Language Environment that no system umask value is in effect. For more information about how Language Environment handles umask processing, refer to z/OS XL C/C++ Runtime Library Reference.

In addition, if a umask value is not specified in BPXPRMxx, the default is NONE, which indicates that no umask default is in effect.

Specify the value by ORing together the following bits:

4000: Set-user-ID bit
2000: Set-group-ID bit
1000: Sticky bit
0400: User read
0200: User write
0100: User execute
0040: Group read
0020: Group write
0010: Group execute
0004: Other read
0002: Other write
0001: Other execute

For example, UMASK(007) will give no access to other.

VERSION('nnnn'[,UNMOUNT|NOUNMOUNT])

The VERSION statement applies only to systems that are exploiting shared file systems. VERSION allows multiple releases and service levels of the binaries to coexist and participate in shared file system. A directory with the value nnnn specified on VERSION is dynamically created at system initialization under the sysplex root that is used as a mount point for the version file system. However, this directory is only dynamically created if the sysplex root file system is mounted read/write.

Specify UNMOUNT to turn on the version auto-unmount option, which will cause the VERSION_AUTO_UNMOUNT attribute to be set for the version file system if it is mounted on this system. If unspecified, NOUNMOUNT is the default at system initialization. If the version string ’nnnn’ is ’/’ (slash), the version auto-unmount option will be set to NOUNMOUNT regardless of what is specified.

Note: nnnn is a case-sensitive character string no greater than 8 characters in length. It indicates a specific instance of the version file system. The most appropriate values for nnnn are the name of the target zone, &SYSR1, or another qualifier meaningful to the system programmer. For example, if the system is at V2R9, you can specify REL9 for VERSION.

When SYSPLEX(YES) is specified, you must also specify the VERSION parameter.

The VERSION value is substituted in the content of symbolic links that contain $VERSION. For scenarios that describe the use of the version file system, see Sharing file systems in a sysplex in z/OS UNIX System Services Planning.

If you are testing or changing to a new maintenance level, dynamically change the VERSION value by using the SETOMVS command.

SETOMVS VERSION='string'

You can also dynamically turn on or off the VERSION_AUTO_UNMOUNT attribute using the SETOMVS command.

SETOMVS VERSION=('string',UNMOUNT|NOUNMOUNT)

Using the SETOMVS command:

If 'string' is specified but not UNMOUNT or NOUNMOUNT, then the current version auto-unmount option is used.
You can specify * instead of ’string’ in order to change only the version auto-unmount option.

You can also change the settings of this parameter by using SET OMVS=(xx) and SETOMVS RESET=(xx) parmlib specifications.

Note: Do not change VERSION dynamically if you have any users that are logged on or running applications because replacing the system files for these users might be disruptive.