Startup Parameter Descriptions

This section describes all FILESERV startup parameters. Except where noted, a startup parameter applies to both multiple user mode and dedicated maintenance mode processing. Startup parameters that do not apply to dedicated maintenance mode operation are ignored in that mode.

ADMIN userid_list
ADMIN identifies one or more virtual machine user IDs that are granted file pool administration authority when the server is started.

If not specified, no one is granted file pool administration authority when a server is started. In this case, the only way to grant someone file pool administrator authority is by issuing the GRANT ADMIN operator command when the server is running in multiple user mode. For more information, see GRANT ADMIN.

Note:
  1. Administration authority may also be granted to server machines that interact with the file pool. For example, if DFSMS/VM is to manage the file pool, additional ADMIN parameters will need to be added. See z/VM: DFSMS/VM Customization for more information.
  2. Administration authority implies superuser status when you are using the OpenExtensions functions.

If this file pool server is to be a FIFO server for one or more other file pool servers, you must establish this file pool server as a file pool administrator for each of those other file pools. This is accomplished by including the virtual machine IDs for the FIFO file pool server in the userid_list for this ADMIN startup parameter for each of the file pool servers the FIFO server serves. A file pool designates another file pool server as its FIFO server through the FIFO startup parameter.

If necessary, additional startup parameter file records can be used to contain file pool administrator user IDs. The ADMIN keyword must appear first on each of the additional records.

ADMIN is applicable to all types of file pool servers. It is ignored by dedicated maintenance mode processing.

BACKUP
NOBACKUP
BACKUP indicates the backup is being handled by file pool repository facilities and automatic backup will occur when repository log usage reaches its threshold. It also means the server maintains the repository logs so they reflect control data changes made since the most recent control data backup. When BACKUP is specified, a current control data backup is always required.

The BACKUP startup parameter requires a DDNAME=BACKUP record exists in the filepoolid POOLDEF file. If the startup parameter BACKUP is in effect and a DDNAME=BACKUP record does not exist in the POOLDEF file, a warning message will be displayed. (The DDNAME=BACKUP record is the default backup destination. This destination can be redirected). Refer to the FILESERV DEFBACKUP command on how to define a file pool backup file. For more information, see FILESERV DEFBACKUP.

BACKUP must be in effect for you to successfully back up the control data using either the BACKUP operator command, STOP operator command, the FILEPOOL CONTROL BACKUP administrator command, or the FILESERV BACKUP dedicated maintenance mode command. When BACKUP is in effect, BACKUP is also the default on the STOP operator command.

Note: When BACKUP is in effect, some dedicated maintenance mode commands will obsolete the current control data backup. This document tells you when it is necessary to back up the control data again. If you ignore those instructions, the server will realize there is no current control data backup and will prevent you from starting multiple user mode operation until a backup is made. In this case, use the FILESERV BACKUP command to back up the control data.

NOBACKUP indicates the server should not automatically back up the control data. When NOBACKUP is in effect, you cannot back up the control data. The RESTORE startup parameter is not allowed if the NOBACKUP startup parameter is specified.

The default is BACKUP.

If you have a dedicated repository file pool server or a server that is acting as both a repository file pool server and CRR recovery server (not recommended), or both a repository server and a FIFO server, it is recommended you use BACKUP and RESTORE startup parameters. If you have a dedicated CRR recovery server, it is recommended you use NOBACKUP and NORESTORE startup parameters.

Note:
  1. FILESERV processing issues a FILEDEF command with a ddname of POOLDEF to define the filepoolid POOLDEF file used in backing up the control data.
  2. To switch from NOBACKUP to BACKUP processing, see Enabling Control Data Backup Processing. To switch from BACKUP to NOBACKUP, see Disabling Control Data Backup Processing. If you change the startup parameter without following the instructions in the appropriate section, subsequent FILESERV commands will display error messages and server initialization processing will not be successful.
  3. When BACKUP is in effect, the repository log minidisks must be large enough to contain the logging generated between control data backups. When NOBACKUP is in effect, the repository log minidisks can be much smaller. For a discussion of how to calculate the repository log size, see Replacing Both File Pool Log Minidisks.
CATBUFFERS catbuf
catbuf indicates the number of 4096-byte virtual storage buffers the server should acquire for use in reading and writing the file pool catalogs. The value catbuf can range from 10 to 32767.
The default is a function of the USERS startup parameter value. The CATBUFFERS default value is: 
(mmmmm/2) + 10

where mmmmm is the value specified (or allowed to default) for the USERS startup parameter.

In dedicated maintenance mode, this startup parameter is computed as described above, even though the USERS startup parameter value otherwise has no meaning in dedicated maintenance mode.

For repository file pool servers, it is recommended you use the CATBUFFERS default value, which is based on the USERS startup parameter.

For dedicated CRR recovery servers or dedicated FIFO servers, the recommended value for catbuf is 10 (the minimum allowable value). If you use the default, there will be a lot of unneeded storage allocated for catalog buffers. Dedicated CRR recovery servers and FIFO servers only have minimal use for catalog buffers compared to repository file pool servers. Therefore, you should specify the value for catbuf rather than using the default for CATBUFFERS.

If you should use the same server for both repository services and CRR recovery services (not recommended) or for both repository services and FIFO services, combine the two values for catbuf that would have been used if SFS and CRR or FIFO services were in separate servers.

CTLBUFFERS ctlbuf
ctlbuf indicates the number of 512-byte buffers the server should acquire for use in reading and writing the file pool control minidisk. The value ctlbuf can range from 10 to 32767.
The default is a function of the USERS startup parameter value. The CTLBUFFERS default value is: 
10 x mmmmm

where mmmmm is the value specified (or allowed to default) for the USERS startup parameter.

In dedicated maintenance mode, this startup parameter is computed as described above, even though the USERS startup parameter value otherwise has no meaning in dedicated maintenance mode.

For repository file pool servers, it is recommended you use the CTLBUFFERS default value, which is based on the USERS startup parameter.

For dedicated CRR recovery servers or FIFO servers, the recommended value for ctlbuf is 10 (the minimum allowable value). If you use the default, there will be a lot of unneeded storage allocated for control buffers. Dedicated CRR recovery servers and FIFO servers only have minimal use for control buffers compared to repository servers. Therefore, you should specify the value for ctlbuf rather than using the default for CTLBUFFERS.

If you should use the same server for both repository and CRR services (not recommended) or both repository services and FIFO services, then combine the two values for ctlbuf that would have been used if the services were in separate servers.

DUMP
FULLDUMP
NODUMP
DUMP indicates a partial virtual machine storage dump (not including code areas) should occur if a server error is detected. If the server is running in an XC mode virtual machine, some of the SFS data spaces may be dumped according to the following:
  • If the server was in access-register mode at the time of the error, each data space accessible by way of an access register is dumped.
  • If the server was not in access-register mode, no SFS data spaces will be dumped.

FULLDUMP indicates a complete virtual machine storage dump (including code areas) should occur if a server error is detected. If the server is running in an XC mode virtual machine, all data spaces created by the server are also dumped.

NODUMP indicates no virtual machine storage dump should occur if a server error is detected.

The default is DUMP.

Each one of these startup parameters is applicable to repository file pool servers, CRR recovery servers, and FIFO servers.

Unless the designated support group for your installation asks you to specify NODUMP or FULLDUMP, you should let the server default to DUMP.

All dumps are in VMDUMP format and are written to a server machine spool file. These dumps can be read using the z/VM® VM Dump Tool.

FILEPOOLID filepoolid
filepoolid is the one-to-eight character file pool ID name for the file pool. The server uses filepoolid as the:
  • File name for the POOLDEF file, which contains the file pool definition information.
  • Transaction program name (TPN) for the file pool. The TPN is sometimes called the resource ID.

Users refer to the file pool by the file pool ID name specified in the FILEPOOLID startup parameter. The file pool ID identifies the TPN you communicate with from a user machine to issue administration commands. The first character of the name must be a character from A through Z and the remaining positions of the name must be from A through Z or 0 through 9. The names SYSTEM, ALLOW, and ANY are not valid. Also, be sure the file pool ID you specify is not the same as a user ID on the system.

If you omit the FILEPOOLID startup parameter, the server uses its own virtual machine ID (also known as the server ID) as the file pool ID.

This startup parameter is applicable to repository file pool servers, CRR recovery servers, and FIFO servers.
Note:
  1. The FILEPOOLID startup parameter is not used for IUCV processing in dedicated maintenance mode. In dedicated maintenance mode, the startup parameter determines the file name for the POOLDEF file that contains file pool definition information.
  2. If this is a repository file pool server and the file pool ID has a VMSYS prefix (such as VMSYS or VMSYSU), then:
    • Server always identifies (using IUCV *IDENT) the file pool ID TPN as a local resource. (The IUCV *IDENT statement in the server's z/VM system directory entry can specify LOCAL or GLOBAL.)
    • The LOCAL and REMOTE startup parameters are ignored, because the file pool ID is always identified as local.
    If this is a repository file pool server and the file pool ID does not have a VMSYS prefix, then:
    • Server always identifies (using IUCV *IDENT) the file pool ID TPN as a global resource. (The IUCV *IDENT statement in the server's z/VM system directory entry must specify GLOBAL.)
    • The LOCAL and REMOTE startup parameters determine whether a user outside the system (TSAF, ISFC, or SNA) can connect to the file pool.
  3. Renaming a repository file pool managed by DFSMS/VM has special implications. For example, if DFSMS file migration is being used, you must also rename the DFSMS Migration Level 1 directory which supports that file pool. See z/VM: DFSMS/VM Customization for more information.
  4. If this is a CRR recovery server, the server always identifies itself (here the reference is not to the file pool ID TPN, but to the TPNs that are reserved for CRR services and discussed in the CRR startup parameter) as a global resource. (The IUCV *IDENT statement in the server's z/VM system directory entry must specify GLOBAL).
    Note: The .luname TPN associated with the CRR recovery server is always global.

    If the file pool ID has a VMSYS prefix (such as VMSYSR), the server identifies (using IUCV *IDENT) the file pool ID TPN as a local resource. The LOCAL and REMOTE startup parameters are ignored, because the file pool ID is always identified as local. In this case, you can only do CRR user machine administration from the same system.

    If the file pool ID does not have a VMSYS prefix, the server identifies (using IUCV *IDENT) the file pool ID TPN as a global resource. The LOCAL and REMOTE startup parameters determine whether a user outside the system (TSAF, ISFC, or SNA) can connect to the file pool. In this case, if the REMOTE startup parameter was selected, you can do remote CRR user machine administration.

  5. The z/VM installation process creates file pools with the following file pool IDs:
    • VMSYS
    • VMPSFS
    • VMSYSU
    • VMSYSR

    If other file pools are already defined on your processor, you should choose a name not already in use on that processor. If your processors are connected in a TSAF or CS collection, the file pool ID you select should be unique in the collection. The collection enforces this uniqueness in all cases except for file pool IDs beginning with VMSYS. So if you choose a name already in use, you will not be able to successfully start the server for multiple user access to that file pool.

    A server always identifies file pools having IDs beginning with VMSYS as LOCAL resources, so it is possible to have duplicate file pool IDs beginning with VMSYS in a TSAF or CS collection (such as the IBM-supplied file pools VMSYS, VMSYSU, and VMSYSR).

FIFO filepoolid
filepoolid is a one-to-eight character file pool ID name of the server that will act as the associated FIFO server. If you omit the FIFO startup parameter, a server uses its own file pool ID as the FIFO server file pool ID.

A file pool server can designate another file pool server to handle its FIFO operations by using the FIFO startup parameter. This allows for off-loading work to another server, presumably one that has little or no repository work to do. The FIFO startup parameter is pertinent only to BFS services, therefore it is ignored for SFS specific services and can be defaulted when only SFS services are used. If it is defaulted, no server-supported FIFO operations will be off-loaded. In this case the startup parameter for FIFO filepoolid defaults to the filepoolid established by the FILEPOOLID startup parameter. Off-loading of FIFO work is not visible to applications that use the server functions.

To understand better this optional splitting of FIFO operations, it is appropriate to understand the nature of the FIFO objects, how they are different from ordinary file objects, and how the file pool server relates to them as a repository manager. A repository file pool server provides two functions for regular files:

  1. definitional or control information for the object, such as its name, type, parent directory (path), and
  2. actual file data.

In the case of an ordinary file, the file data is stored on DASD and has specific recovery characteristics. On the other hand, FIFO objects involve similar definitional information, but the data is transitory and is not stored on DASD. That is, the data for a FIFO is kept in memory and disappears when the FIFO is closed. In this sense this FIFO data can be considered non-repository data, while the control for the FIFO (for example, its type, name) is considered part of the file pool repository.

With this in mind, it is easier to understand the nature of the functional split between the file pool server repository where the FIFO is defined and the file pool server where its transitory read/write operations are handled, as supported by the FIFO startup parameter. The repository function for the FIFO is not affected by the off-load; only the transitory, non-repository functions of the FIFOs are off-loaded.

FIFO service work for a file pool server potentially involves fairly high volumes of short messages from FIFO read and write operations. Such operations could potentially consume considerable resources in the file pool server where the FIFOs are defined. If a high volume of such activity is anticipated for the BFS applications that use the file pool, it is recommended you establish another server for off-loading the FIFO read/write activity for the file pool repository. Any file pool server can be designated a FIFO server, although it must be resident in the same system as the file pool that designates it.

When you specify a separate file pool for doing FIFO services, you must also set up administrative authority (with the respective ADMIN start up parameters) such that the FIFO server has administrative authority to the repository file pool that it is servicing, and, (vice versa) the repository file pool server has administrative authority for the FIFO server. Even when the FIFO read and write work is off-loaded to another server, it is occasionally necessary to communicate between the file pool server where the FIFOs are defined (repository) and the file pool server to which read and write operations are off loaded (FIFO server). For this reason, a separate FIFO server must have administrator authority for the file pool for which it is doing FIFO services. When you specify another file pool server in this FIFO startup parameter, you must be certain the ADMIN startup parameter for the same server includes the FIFO file pool server's virtual machine ID to establish administrator authority for the FIFO server.

A file pool server may act as a FIFO server for any number of other file pools. A system may have any number of FIFO servers. A FIFO server may also support file pool repository services (BFS or SFS) of its own. The FIFO parameter allows you to control this load balancing to meet your individual requirements.

Although the FIFO server must be in the same system as the file pool that defines it, VM user machines may be in other systems. Allowance for remote file pool users is a normal feature of file pool servers. The FIFO server simply retains this file pool service characteristic.

FORMAT
NOFORMAT
FORMAT indicates certain FILESERV commands should enter CMS FORMAT and RESERVE commands for various minidisks, as follows:
  • FILESERV GENERATE–issues FORMAT and RESERVE for the control minidisk, repository log minidisks, CRR log minidisks (if this is a CRR recovery server), and all minidisks allocated to storage groups.
  • FILESERV MINIDISK–issues FORMAT and RESERVE for the storage group minidisks being added.
  • FILESERV LOG–issues FORMAT and RESERVE for both repository log minidisks.
  • FILESERV CRRLOG–issues FORMAT and RESERVE for both CRR log minidisks.

The FORMAT or NOFORMAT startup parameters are ignored by all other FILESERV commands. You will not see the prompts that FORMAT and RESERVE commands usually issue; the FILESERV commands respond to the prompts internally.

NOFORMAT indicates FILESERV GENERATE, FILESERV MINIDISK, FILESERV LOG, or FILESERV CRRLOG should not issue CMS FORMAT and RESERVE commands for the indicated minidisks. If new file pool minidisks are being used by these commands, you must ensure CMS FORMAT and RESERVE commands are entered for them. (See #4 for instructions on using the CMS FORMAT and RESERVE commands.)

Note: A file pool control minidisk requires a block size of 512, and repository log minidisks, storage group minidisks, and repository log minidisks require a block size of 4096.

The default is FORMAT.

Each one of these startup parameters is applicable to repository file pool servers, CRR recovery servers, and FIFO servers.

GROUPTHRESH threshold_percent
Indicates a threshold percentage. When threshold_percent percent of the physical space allocated to any storage group is used, the server displays a warning message on its operator console. The message identifies the storage group that is becoming full. This startup parameter is provided so you can know in advance when more DASD storage will be needed.

The value threshold_percent can range from 1 to 99. If you do not specify a GROUPTHRESH value, the default for threshold_percent is 90, which means the threshold message is displayed when a storage group is 90% full.

This startup parameter is applicable to repository file pool servers, CRR recovery servers, and FIFO servers. For dedicated CRR recovery servers and for dedicated FIFO servers, use the default value.

LOCAL
REMOTE
SSI
If the FILEPOOLID startup parameter's filepoolid has a VMSYS prefix (for example, VMSYS, VMSYSU, or VMSYSR), the LOCAL, REMOTE, and SSI startup parameters have no significance. VMSYS file pool ID TPNs are always identified as a local resource, therefore this startup parameter is always a logical LOCAL regardless of whether you specify LOCAL or REMOTE or SSI.

For file pool IDs that do not have a VMSYS prefix, LOCAL indicates the server should not accept a file pool ID connection from outside the processor in which it is running.

For file pool IDs that do not have a VMSYS prefix, REMOTE indicates the server should accept a file pool ID connection from outside the processor in which it is running.

For file pool IDs that do not have a VMSYS prefix, SSI indicates the server should accept a file pool ID connection from outside the processor in which it is running, but only if the request is from another member of the same single system image cluster.

The default is LOCAL.

Each one of these startup parameters is applicable to repository file pool servers, CRR recovery servers, and FIFO servers.

Note: The TPNs that identify a CRR recovery server (see the startup parameter description, CRR) are always set up to accept remote connections (from participating resource managers and other CRR recovery servers, not from SFS repository file pool users).
NOACCOUNT
ACCOUNT
ACCOUNT indicates the server should generate accounting records when processing in multiple user mode. (The server never generates accounting records in dedicated maintenance mode—so this startup parameter is ignored in dedicated maintenance mode.) The accounting records are placed in the z/VM system accounting file.

NOACCOUNT indicates no accounting records should be generated in multiple user mode.

The default is NOACCOUNT. See Accounting for more information about accounting.

Each one of these startup parameters is applicable to repository file pool servers, CRR recovery servers, and FIFO servers.

NOAUDIT
AUDIT
NOAUDIT indicates server security audit processing should not be performed in multiple user mode. (The server never audits security in dedicated maintenance mode—this startup parameter is ignored in dedicated maintenance mode.)
AUDIT indicates security audit processing should be performed in multiple user mode. Security audit processing, in this case, generates a record in an output file for:
  • Unsuccessful repository access attempts
  • Successful repository access attempts because special authority (for example, administrator access to objects owned by other users)
  • Use of the CRR recovery server operator command:
    • CRR ERASE LU
    • CRR ERASE LUWID
    • CRR RESYNC
  • Use of these repository file pool server commands:
    • ERASE LUNAME
    • FORCE PREPARED

This audit is equivalent to one started by an AUDIT ON PARTIAL operator command. The audit output is written to the file identified by the ddname AUDIT. If an error occurs while opening the output file, server processing stops.

The default is NOAUDIT.

Each one of these startup parameters is applicable to repository file pool servers. CRR recovery servers, and FIFO servers.
Note:
  1. Each one of these startup parameters does not apply to, and is ignored by, dedicated maintenance mode processing.
  2. The ddname=AUDIT file has the following characteristics: 
    RECFM=VB   LRECL=384   BLOCK=4096
  3. See Auditing Security for more about auditing file pool and CRR log security. To change the level of auditing (partial or complete) or to selectively audit CRR recovery server operator commands after multiple user mode processing is started, use the operator command, AUDIT.
NOCRR
CRR
NOCRR indicates the server is not going to be the designated CRR recovery server.

CRR indicates the server is going to be the designated CRR recovery server. It also can be used to designate the CRR recovery server either during file pool generation or it can make an already generated server the designated CRR recovery server.

When the server detects the CRR startup parameter is in effect, the server automatically issues a *IDENT for each of the different transaction program names (TPNs) reserved for the following CRR functions:
  • CRR logging. (The TPN is identified as a local resource.)
  • Communication between this CRR recovery server and AVS. (The TPN is identified as a local resource.)
  • Communication between this CRR recovery server and another CRR recovery server on another system for resynchronization. (The TPN is identified as a system resource.)
  • Communication between this CRR recovery server and a participating resource manager (such as an SFS repository file pool server). (The TPN is identified as a global resource.) This TPN is derived from the CRR recovery server's LUNAME startup parameter (does not include netid).
    Note: If the luname value specified in the LUNAME startup parameter is eight characters (maximum allowable length), the first character in luname is truncated to allow for the dot prefix. For example, if you specify: 
    LUNAME mynodeid.myluname
    the mapping to the *IDENT value is ‘.yluname’, not ‘myluname’.

The four different TPNs are used by the server to identify itself as the CRR recovery server machine. These TPNs are reserved for CRR services and must not be used by another user.

Only one server on a system can specify the CRR startup parameter because one and only one CRR recovery server can be running on a system. An IBM-supplied CRR recovery server can be optionally installed during the z/VM installation process or you can generate your own CRR recovery server in a post installation procedure.

The default is NOCRR.

Each one of these startup parameters is applicable to SFS repository file pool servers and CRR recovery servers. When a repository file pool server is only involved in BFS file space activity, there is no active CRR recovery server involvement. However, if no CRR recovery server exists in the z/VM system, then performance can be degraded in those cases where SFS services are used in conjunction with administering BFS file spaces.
Note:
  1. If the CRR startup parameter is specified, the server opens (connects) the CRR logs. If this open is unsuccessful, an error message indicating this is issued to the server console and processing is stopped.
  2. If you already have a CRR recovery server running and you attempt to bring up another server with the CRR startup parameter, error messages are issued to the server console and processing is stopped.
NODFSMS
DFSMS
NODFSMS indicates DFSMS/VM is not managing the file pool. This is the default parameter.

DFSMS indicates DFSMS/VM is managing the file pool. Therefore, the DFSMS/VM exit routine will be called at certain times.

Note: The VMSYS file pool must be up for DFSMS/VM to function correctly.

If the CSL routine handles the DFSMS/VM exits does not exist, a return code indicating the exit should not be called again will be returned.

Specifying the DFSMS parameter indicates you wish DFSMS/VM to manage the file pool. This has implications for the file pool that you should be aware of, including:
  • Backup
  • Moving a user to a different storage group
  • Enrolling users

The use of DFSMS/VM to manage a file pool should be part of an overall repository storage management strategy. For more information about DFSMS/VM and how it can help you manage repository file pools, see z/VM: DFSMS/VM Planning Guide and z/VM: DFSMS/VM Storage Administration.

If you specify DFSMS and DFSMS/VM is not installed, you will receive the following error messages: 
DMS2030I Initialization error in exit routine SMSDFSMS
Return code = -7, reason code = 0

This parameter is ignored in dedicated maintenance mode.

For dedicated CRR recovery servers or dedicated FIFO servers, you should always specify, or let the value default, to NODFSMS. Note that you must not specify DFSMS for the VMSYS file pool. If you do, the server will stop and you will receive the following error message: 
DMSSSH2030I Initialization error in exit routine SMSDFSMS
Return code = 12, reason code = 100

Additional system setup is required to install DFSMS. For more information, see z/VM: DFSMS/VM Customization.

Note: If the DFSMS parameter is specified, FILESERV processing uses RTNLOAD to load FSMINT and VMLIB, libraries containing CSL routines reserved for IBM use. These libraries must be present on a file mode accessed by the repository file pool server. If either is not found, message 
DMS1136E Unable to gain access to library libname
is issued and FILESERV processing continues as if NODFSMS had been specified. If you wish to run with DFSMS enabled, take corrective action by first stopping the server using the STOP NOBACKUP operator command. Ensure the CSL library identified in the message is present on an accessed file mode, and restart the server using the FILESERV START command.
NOESECURITY
ESECURITY
NOESECURITY indicates file pool access is not controlled by an external security manager (ESM).

ESECURITY indicates file pool access is controlled by an ESM. The server looks for a file called DMSESM PROFILE, which defines the interface with the ESM. This file contains three types of records:

  1. The name of the CSL routine the server calls during initialization and termination of the system. You can also specify in this record if you want to allow the ESM to defer a security check back to the usual SFS authorizations.
    Note: The initialization and termination CSL routine can interface directly with the ESM or through a portion of the ESM code, called the security adapter, loaded into the server machine. The initialization and termination CSL routine specified in the supplied DMSESM PROFILE calls a module named RPIUCMS to enable the ESM. However, RPIUCMS MODULE is not supplied with z/VM. If you plan to use the RPIUCMS interface to the ESM, you must provide the RPIUCMS MODULE. (The ESM might supply its own RPIUCMS MODULE.) If RPIUCMS is missing or cannot be invoked, server processing ends with an error.
  2. A list of the types of calls the ESM is to review, including the name of the CSL routine used for each type of call. Four types of calls can be directed to the ESM:
    • SFS object authorization check
    • SFS command authorization check
    • SFS operator command authorization check
    • ESM program check
  3. A list of specific file pool requests, if any, the ESM must review.

You can tailor the DMSESM PROFILE to meet the needs of your installation. You can also customize the ESM interface by modifying the supplied CSL routines or writing your own.

Prior to specifying ESECURITY, you should review the MAXCONN parameter of the OPTION control statement in the z/VM system directory entry for the server machine. (See z/VM: CP Planning and Administration for details.) Depending on how many connections the ESM uses, you might want to add some connections to MAXCONN.

ESMs are not used in dedicated maintenance mode. The ESECURITY startup parameter is ignored if specified for a dedicated maintenance mode command.

The default is NOESECURITY.

The ESECURITY startup parameter is applicable to all file pool servers, but it is recommended that dedicated CRR recovery and dedicated FIFO servers use the default of NOESECURITY.

For more information about external security managers, see Using an External Security Manager.

NOETRACE
ETRACE
NOETRACE indicates server external trace processing should not be performed.

ETRACE indicates server external trace processing should be performed for all server processing beginning with initialization. If ETRACE processing cannot be started, the server displays an error message and ends.

The default is NOETRACE.

Each one of these startup parameters is applicable to repository file pool servers, CRR recovery servers, and FIFO servers.
Note:
  1. You should use the ETRACE facility only when requested by the designated support group for your installation.
  2. Refer to the operator command, ETRACE for a description of server external trace processing.
  3. If the server is started in multiple user mode, the ETRACE parameter causes tracing of server functions at the most complete level of detail. The only reason you should specify ETRACE for a multiple user mode startup (FILESERV START) is if you want to trace server initialization. Otherwise, you should use the ETRACE operator command in multiple user mode to start and stop external tracing.

    If you do specify ETRACE in multiple user mode, you can use the ETRACE OFF operator command to stop the complete tracing, and then enter ETRACE ON to resume a selective trace. (ETRACE ON prompts you for specific subcomponents and functions.)

  4. If the server is started in dedicated maintenance mode, prompts will be issued to allow the type of subsequent external trace processing to be specified. Refer to the ETRACE operator command for a description of the valid prompt responses.
NOITRACE
ITRACE buffersize
NOITRACE indicates server internal trace processing should not be performed.

ITRACE buffersize indicates server internal trace processing should be performed for all server processing beginning with initialization.

The buffer size is the amount of virtual storage in the server machine to be used for internal tracing. The buffersize value represents the number of bytes to be used for the buffer in 1024-byte (1KB) units. The server rounds the amount to the next highest multiple of 4096 (4KB) bytes. For example, a buffersize value of 1, 2, 3, or 4 will result in a 4096-byte buffer while a value of 5, 6, 7, or 8 will result in a 8192-byte (8KB) buffer. If you specify a buffer size value, it must be equal to, or greater than 1.

If a buffer size value is not specified, a default value of 16 is used. This results in a 16384-byte (16KB) buffer. The maximum buffer size is 2097148KB. If the ITRACE buffer cannot be acquired, the server displays a message and stops.

The default is NOITRACE.

Each one of these startup parameters is applicable to repository file pool servers, CRR recovery servers, and FIFO servers.

Note:
  1. You should use the ITRACE facility only when requested by the designated support group for your installation.
  2. Refer to the operator command, ITRACE for a description of server internal trace processing.
  3. This startup parameter does not apply to and is ignored by dedicated maintenance mode processing.
NOLUNAME
LUNAME luname
LUNAME luname supplies the fully qualified LU name to this CRR recovery server. Specify NOLUNAME when the file pool server does not act as a CRR recovery server. The LUNAME startup parameter is required at FILESERV GENERATE if the CRR startup parameter is specified, and it is also required when FILESERV CRRLOG is entered. This startup parameter is ignored at all other times.

The default is NOLUNAME.

The LUNAME startup parameter is required for CRR recovery servers. It is recommended that the other file pool servers use the default of NOLUNAME.
Note:
  1. The fully qualified LU name must be in the form:
    Read syntax diagramSkip visual syntax diagram netid. luname
    where:
    • netid is an optional SNA network ID of 0 to 8 characters in length followed by a period. (The period is optional if netid is omitted.) A netid is required if this CRR recovery server is part of an SNA network.
    • luname is an LU name 1 to 8 characters in length.

    The netid or luname must consist of EBCDIC uppercase letters (A-Z), numerics (0-9), $, #, or @. The first character must be nonnumeric.

  2. This fully qualified LU name MUST be unique in the SNA network. In other words, you must not have two recovery servers with the same name. This fully qualified LU name will be used internally whenever the CRR recovery server has to exchange log names with another CRR recovery server or participating resource manager, and when generating unique logical unit of work IDs (LUWIDs). The fully qualified LU name specified must be a legitimate LU name for your system.

    If the environment changes, the LU name may have to be changed. For example, assume your system was local and you did not specify an SNA network ID. If your system became part of an SNA network, you would have to specify an SNA network ID in the LU name.

    The LU name can only be changed by supplying a new one when running either FILESERV GENERATE or FILESERV CRRLOG. The LU name must adhere to the format of SNA network name definitions. See z/VM: Connectivity.

  3. This LU name also derives one of the CRR recovery server's reserved TPNs. When the LU name is eight characters in length, the leftmost character is replaced with a dot (.) in the formation of the CRR recovery server's derived TPN. If the remaining seven characters are not unique in the scope of the TSAF or CS collection, you will get message DMS3365E when the CRR recovery server attempts to identify this reserved TPN using the *IDENT function at CRR recovery server initialization time. If this occurs, one of the CRR recovery servers (the one already initialized or the one encountering the DMS3365E message) must change its LU name to one that will permit the unique TPN derivation. The procedure for a CRR recovery server to make this LU name change is described above in note 2. See the description of the startup parameter, CRR for a list of the reserved CRR TPNs.
Rules for creating LU names if the CRR recovery server resides on a system that is:
  • Part of an SNA network:
    • The netid must be the same as an SNA network ID value defined to VTAM for this processor.
    • The luname must be the same as an LU name defined to VTAM that represents one of the AVS gateways for this processor.
    • The netid.luname must be unique among CRR recovery servers and their non-z/VM LU 6.2 sync point equivalents.
  • Part of a TSAF or CS collection:
    • The netid can be omitted (but you may specify the SNA network ID if you know in the future your system will be part of an SNA network).
    • The luname must be the same as the node ID associated with this processor.
    • The luname must be unique among CRR recovery servers.
    Note: If you can connect to another system within your TSAF or CS collection that has AVS, you have access to the SNA network. In this case, you should follow the rules for a system that is part of an SNA network.
  • Local only (not part of a TSAF or CS collection or an SNA network):
    • The netid can be omitted (but you may specify the SNA network ID if you know in the future your system will be part of an SNA network).
    • The luname can be any valid name.

For information on changing LU names, see Remove Designation of Alternate CRR Recovery Server.

NOMSGS
MSGS
NOMSGS indicates informational server startup and processing messages should not be written to the server machine console. Messages such as those that display the contents of the filepoolid POOLDEF file are not written when the NOMSGS parameter is in effect.

MSGS indicates the informational messages should be displayed.

The default is NOMSGS.

Each one of these startup parameters is applicable to repository file pool servers, CRR recovery servers, and FIFO servers.

NORESTORE
RESTORE
NORESTORE indicates the file pool control data should not be restored during startup processing.

RESTORE indicates the control data should be restored before usual server operation is initiated. When RESTORE is in effect, you must enter a FILEDEF command for ddname RESTORE before entering the FILESERV START command. The file identified by ddname RESTORE must contain a backup of the control data. That is, the file identified by ddname RESTORE should be the same file identified by ddname BACKUP in a previous control data back up. The file can be either a disk or tape file. If ddname RESTORE is not defined, the server displays an error message and stops.

When FILESERV START is entered, the server replaces the control data with the backup copy in the file identified by ddname RESTORE. After restore processing completes successfully, the server immediately initiates usual multiple user mode operation.

The default is NORESTORE.

Note:
  1. This startup parameter does not apply to and is ignored by dedicated maintenance mode processing.
  2. When the RESTORE startup parameter is specified:
    1. FILESERV command processing issues a FILEDEF command for DDNAME=POOLDEF to define the filepoolid POOLDEF file.
    2. FILESERV START processing updates the filepoolid POOLDEF file.
    3. FILESERV START processing creates and usually erases a temporary file named $$SAVED $POOLDEF using the same file mode as that of the filepoolid POOLDEF file. If $$SAVED $POOLDEF already exists on that file mode, FILESERV START processing displays an error message and stops.
  3. If the FILESERV START command ends unusually and the RESTORE parameter was specified:
    1. If message DMS3292I was displayed, the restore process completed, but the log recovery process did not. In this case, it is not necessary to do the restore over. When you next start multiple user mode processing with the NORESTORE startup parameter, the server will automatically do the log recovery.
    2. If message DMS3292I was not displayed, the restore process did not complete and needs to be rerun. In this case, if the $$SAVED $POOLDEF file exists with the same file mode as that of the filepoolid POOLDEF file, erase the filepoolid POOLDEF file. Then rename $$SAVED $POOLDEF to filepoolid POOLDEF. For example, if the file pool ID is VMSYSU, and the POOLDEF file resides on file mode A, you would enter: 
      erase vmsysu pooldef a
rename $$saved $pooldef a vmsysu pooldef a
  4. The RESTORE startup parameter can be specified only if the BACKUP startup parameter is also in effect. If the RESTORE and NOBACKUP startup parameters are specified, an error message is displayed, and FILESERV command processing stops.
  5. The RESTORE startup parameter is only used to recover the file pool by restoring control data using the last control data backup. For usual startup, this is not required and the NORESTORE startup parameter should be specified.
  6. The only backup file that will restore successfully is the last backup file created. If you try to restore any earlier control data backup, the restore will not succeed. An error message will be displayed, and server processing will stop.
  7. This note applies only to repository file pool servers and should be ignored in the case of dedicated CRR recovery servers and dedicated FIFO servers. For best performance when restoring the control data, you should also specify a very large catalog buffer pool. To increase the size of the catalog buffer pool, specify the CATBUFFERS startup parameter. 
    CATBUFFERS 5000

    If the server machine does not have enough virtual storage available to it, you may need to reduce the CATBUFFERS value.

    If you do specify a large catalog buffer pool, you should plan to stop multiple user mode processing soon after the restore completes to reset CATBUFFERS to its usual value.

  8. It is convenient to have a startup parameter file used only for restores.

For more instructions on restoring the control data, see Restoring Control Data.

RESYNCINTERVAL timed_wait
This startup parameter sets the amount of time (called the timed wait interval) spent in a wait state before the next attempt at resynchronization. Resynchronization attempts to connect to either a CRR recovery server (for protected conversations) or a participating resource manager (such as an SFS repository file pool server) to try to complete an LUWID instance. The cycling through timed waits and attempts at resynchronization is called the automatic periodic retry of resynchronization.
Note: An LUWID instance is a subset of a coordinated transaction (also called a CRR logical unit of work). The coordinated transaction is identified by the LUWID. The LUWID instance can consist of one or more resource logical units of work.

Also, the RESYNCINTERVAL startup parameter determines the frequency the CRR recovery server operator is reminded of LUWID instances waiting to be resynchronized.

timed_wait is the number of seconds the CRR recovery server should wait between attempts at completing resynchronization.

If the RESYNCINTERVAL startup parameter is not specified for the CRR recovery server, the default value is 600 seconds (10 minutes).

This startup parameter is applicable to CRR recovery servers.

SAVESEGID savesegname
NOSAVESEGID
This startup parameter identifies the location of the server executable code. If omitted or if SAVESEGID is specified without a savesegname, CMS executes the server code residing in a physical saved segment named CMSFILES.

If SAVESEGID is specified with savesegname, savesegname must identify a segment that contains server executable code. If NOSAVESEGID is specified, the server's executable modules are loaded as nucleus extensions.

When you have multiple file pool servers, it is more desirable to specify SAVESEGID. Specifying SAVESEGID allows multiple servers to share one copy of server executable code.

Each one of these startup parameters is applicable to repository file pool servers, CRR recovery servers, and FIFO servers.

SHUTDOWNSIGNAL
NOSHUTDOWNSIGNAL
SHUTDOWNSIGNAL indicates the server is enabled to receive a shutdown signal from CP. When a CP SHUTDOWN, FORCE, or SIGNAL command is issued, CP sends a shutdown signal to all enabled file pool servers. When an enabled server receives the shutdown signal from CP, the SFS STOP operator command (with no operands) is automatically issued. At the completion of the STOP command, SFS notifies CP the shutdown has completed. If this processing does not complete within a CP-maintained time interval, CP shuts down and SFS is terminated.

NOSHUTDOWNSIGNAL indicates the server is not enabled to receive the shutdown signal.

The default is SHUTDOWNSIGNAL.

Each one of these startup parameters is applicable to repository file pool servers, CRR recovery servers, and FIFO servers.

USERS users
For repository file pool servers, users is your best estimate of the number of logged-on repository users expected during peak system activity. A repository user is someone who accesses objects in either SFS or BFS file spaces in a file pool repository server. (The value should be the same as the USERS value used in calculating the MAXCONN value for the server machine as described in Generating a File Pool and Server.)

For CRR recovery servers, users is your best estimate of the number of logged-on CRR users you anticipate exploiting CRR by doing sync point processing (two-phase commit). The default of 100 should be sufficient for many installations.

Note:

It is strongly recommended you do not use the same server for both file pool repository and CRR services. However, if you do so, combine the two values for users that would have been used if the file pool repository and CRR services were assigned were to separate servers.
For FIFO servers, users is determined as follows:
  • If FIFO service is done by the repository server (FIFO startup parameter defaulted), there are no adjustments to users for the FIFO service.
  • If the current startup is for a file pool server that is doing FIFO services for one or more other file pool servers (ones that specified in their FIFO startup parameter the file pool that is currently being started-up), users should include BFS users for each of those other file pool servers, where those BFS users actively employ FIFO objects. That is, you should allow for the total of all potential concurrent BFS FIFO users serviced by the current FIFO server.
If the current file pool server provides both its own repository services and FIFO services for other file pools, users should include the combination of the value calculated for current file pool repository users with the value calculated above for other file pool FIFO users.

An error occurs if you specify a numeric value of less than 1 or greater than 32767. The default value is 100.

This startup parameter is applicable to repository file pool servers, CRR recovery servers, and FIFO servers.

Note:
  1. Choose users carefully. The server optimizes its processing based on this value.
  2. In dedicated maintenance mode, this startup parameter is used only to calculate the CATBUFFERS and CTLBUFFERS values. You do not need to change the USERS value when running the server in dedicated maintenance mode.