Configuring the zDMF server parameters

About this task

The zDMF server Started Task JCL specifies the Configuration PDS member that contains the startup parameters. The sample zDMF server Configuration file is in HLQ.IBM.HGZD341.SGZDSAMP(CONFIG). Comments can be added to the zDMF server Configuration file by using an asterisk in column 1. The entire line is treated as a comment. A semi-colon can be placed outside of a parameter definition and the remainder of the line is considered a comment. In this example, the text ; Command Prefix is treated as a comment:

CPFX=ZD             ; Command Prefix

A semicolon can also be coded in column 1 to comment the entire line.

The following server parameters are listed in the order in which they appear in the CONFIG member.

SUBNAME

SUBNAME=subsysID
Where subsysID is the name you specify for the subsystem.
Synopsis: The zDMF server operates within a subsystem. The SUBNAME parameter identifies the subsystem identifier that you choose.
Note: This does not correspond with the hardware SSID.
Example: SUBNAME=ZDMF
Default: None
Choosing a Subsystem Identifier:
Choose a three- or four-character subsystem identifier that is unique across the installation. The DISPLAY SSI,LIST operator command (can be abbreviated to D SSI,L) can be used to determine which subsystems are currently active or defined on each system. For example:
```
D SSI,L                                               
IEFJ100I  hh.mm.ss  SSI DISPLAY nnn
SUBSYS=JES2 (PRIMARY)                                 
   DYNAMIC=YES     STATUS=ACTIVE       COMMANDS=REJECT
SUBSYS=MSTR                                            
   DYNAMIC=NO      STATUS=ACTIVE       COMMANDS=N/A   
SUBSYS=LOGR                                           
   DYNAMIC=YES     STATUS=ACTIVE       COMMANDS=REJECT
SUBSYS=SMS                                            
   DYNAMIC=YES     STATUS=ACTIVE       COMMANDS=REJECT
SUBSYS=RACF                                           
   DYNAMIC=YES     STATUS=ACTIVE       COMMANDS=REJECT
SUBSYS=ZDMF
   DYNAMIC=YES     STATUS=ACTIVE       COMMANDS=ACCEPT
SUBSYS=GOAL                                           
   DYNAMIC=NO      STATUS=INACTIVE     COMMANDS=N/A 
```
Note: The chosen subsystem name must not match the zDMF started task cataloged procedure name, unless you intend to start zDMF under control of the MSTR subsystem, with no SYSOUT data definitions, and with the cataloged procedure saved in the IEFPDSI library specified in the Master JCL. If you want to use the same name (such as zDMF) for both the subsystem and the cataloged procedure, you have two options. Either remove the SYSOUT DD statements and move the cataloged procedure to the IEFPDSI library, or specify the primary job entry subsystem in the start command. For example, S ZDMF,SUB=JES2

CPFX

CPFX=command prefix
Where command prefix is a unique one- to eight-character string.
Synopsis: CPFX identifies the command prefix for entering zDMF server operator commands.
Default: None
Example: CPFX=ZD
Choosing a command prefix:
You must decide on a command prefix, preferably starting with a non-alphanumeric character. zDMF supports a command prefix of up to eight characters, any or all of which can be alphabetic, however, a short, non-alphabetic prefix is usually the best choice.
- If you plan to use the ISPF Monitor, CPFX must not have more than 4 characters.
- If only the batch facility is used, CPFX can have up to eight characters. However, but an inability to communicate with the server through the ISPF Monitor results.
  The DISPLAY OPDATA,PREFIX operator command (which can be abbreviated as D O) can be used to determine which command prefixes are currently in use across the sysplex. For example:
```
D O                                                          
IEE603I hh.mm.ss OPDATA DISPLAY nnn 
PREFIX      OWNER      SYSTEM     SCOPE     REMOVE   FAILDSP 
 (          OPSSATM    GZD2       SYSTEM    NO       PURGE 
 (          OPSSATM    GZD1       SYSTEM    NO       PURGE   
 !          OPSSOSF    GZD2       SYSTEM    NO       PURGE   
 !          OPSSOSF    GZD1       SYSTEM    NO       PURGE   
 $          JES2       GZD2       SYSTEM    NO       SYSPURGE
 $          JES2       GZD1       SYSTEM    NO       SYSPURGE
```
  Note: If you receive message GZD0047S at server startup, the usual user response is to choose another command prefix. It is possible, however, for the server to terminate in a manner that does not deactivate the command prefix. In this case, the correct response is to code the following in the startup configuration file.
```
CPFX=(xx,FORCE)
```

DB

DB=dsname
Where dsname is the name of a data set that is the zDMF Database.
Synopsis: DB identifies the fully qualified, cataloged data set that is the zDMF Database. See Allocating the zDMF Database for more details on the zDMF Database.
Example: DB=HLQ.IBM.HGZD341.DB
Default: None

ZDPFX

ZDPFX=dsn_prefix
Where dsn_prefix is concatenated with ZDvolser.DB to form the unique name that the zDMF server can allocate, as required, on each target volume to communicate track mirroring status. These data sets are known as extent map files.

Attention: The value of ZDPFX must be identical for all zDMF systems.
Synopsis: The zDMF server places a data set requiring 10 cylinders of space on each volume that is the target of a migration. zDMF uses the data set to communicate the status of mirroring operations for managed data set extents on the volume.
Each generated data set name must be unique within your environment. If multiple configuration data sets are being used, the dsn_prefix value must be specified in exactly the same way for every participating zDMF server.

When a prefix set it is difficult to change it. A change requires, the following actions:
- Complete or deactivate all migration groups,
- shut down all the active zDMF servers,
- delete and reallocate the main zDMF database,
- then initiate a zDMF cold start.
Example: ZDPFX=HLQ.IBM.HGZD341.EXTMAP
The operation creates a HLQ.IBM.HGZD341.EXTMAP.ZDxxxxxx.DB extent map data set on every target volume, where xxxxxx is the target volume serial number.
Default: None

DWA_ADD_PAGE

DWA_ADD_PAGE=additional 4K page count
Where additional 4K page count is a value 0 - 128.
Synopsis: DWA_ADD_PAGE is a global keyword that is used only on disruptive start (START=COLD). It specifies the number of disabled 4 K work area pages to be added to the default number.
Default: 0
By default, the number of 4 K disabled work area pages that are allocated in E/SQA is set to 26 for each processor. Of the 26 pages, 25 are for use by the channel scan logic. A total of 25 pages allows for 647 channel command words (CCWs) for each channel program. When a channel program exceeds this CCW limit, the GZD3310I message is written to the system log, for example:
GZD3310I CP SCAN CONDITION: SIO,NZD00CPY,543C,BUFREJ,SHORTAGE,9E,CCW,647
You can set DWA_ADD_PAGE to increase this allowance. The value that you specify for DWA_ADD_PAGE is added to the default 26 pages to allow for larger channel programs. For each additional page added, zDMF can process an extra minimum of 30 CCWs. The total CCWs capable of being processed as follows:
```
INT((DWA_ADD_PAGE*4K)/136)+647 
```
As the pages are allocated to E/SQA, you must carefully consider the value that you assign to DWA_ADD_PAGE, along with the SQA parameter in the z/OS IEASYSxx PARMLIB member.
Examples:
- DWA_ADD_PAGE=16: zDMF can process an extra 481 CCWs. With the base 647 CCWs, zDMF can process channel programs up to 1128 CCWs in size.
- DWA_ADD_PAGE=64: zDMF can process an extra 1927 CCWs. With the base 647 CCWs, zDMF can process channel programs up to 2574 CCWs.

MAXIO

MAXIO=number
Where number is the maximum number of overall requests that can be active at one time on the server. The minimum value is 0 and the maximum value is 100. If you choose 0, or do not specify a value, the number of overall requests defaults to 25.

Attention: This parameter has a direct impact on the amount of fixed page memory that is used by zDMF. Specifying too large a value can negatively affect overall system performance or exhaust available page space.
Synopsis: MAXIO determines the maximum overall number of I/O requests that can be active at one time on the server. Since I/O buffers and control areas are allocated based on the MAXIO value, you must choose a number appropriate to the resources available.
Approximately 1 MB of memory is allocated for each integer you add to the MAXIO specification; for example, 25 MB for a MAXIO value of 25. The memory allocation is fixed during active I/O.
Default: 25
Example: MAXIO=15

MAX_CHANNEL_IO

MAX_CHANNEL_IO=Requests
Where Requests is the maximum number of concurrent I/O requests. The smallest value is 0 and the maximum value is 100. If you choose 0, or do not specify a value, the number of concurrent I/O requests defaults to 15.

Note: The MAXCIO parameter can be changed on each LPAR with a system console command. The syntax is as follows: xxMAXCIO nn where xx is the user's CPFX value, and nn is an integer. Note that the SET command is not used for this parameter.
Synopsis: Specifies the maximum number of concurrent I/O requests to be issued to a channel during the Copy phase or Mirror Synchronization phase.
The MAX_CHANNEL_IO limit applies to any active I/O against a channel group, whether read or write. If the source and target devices are on the same channel group, zDMF allows total concurrent I/O requests on the channel to equal the value that is specified.
Default: 15
Example: MAX_CHANNEL_IO=5

MAX_DEVICE_IO

MAX_DEVICE_IO=Requests
Where Requests is the maximum number of concurrent I/O requests. A value of 0 to 5 may be specified. If you choose 0, or do not specify a value, the number defaults to 3.
Synopsis: Specifies the maximum number of concurrent I/O requests to be issued to devices that contain a data set migration pair, during the Copy phase or during the Mirror Synchronization phase.
Note: The MAXDIO parameter can be changed on each LPAR with a system console command. The syntax is as follows: xxMAXDIO nn where xx is the user's CPFX value, and nn is an integer. Note that the SET command is not used for this parameter.
Default: 3
Example: MAX_DEVICE_IO=2

IDLE

IDLE=nnnn
Where nnnn is the minimum number of seconds another LPAR must be mute before it is considered IDLE.
Synopsis: Indicates the minimum number of seconds another LPAR must be mute before it is considered IDLE. This value can be altered through the IDLE command and displayed by using the D DEBUG MISC command.
If system contention is suspected to cause zDMF servers to be incorrectly considered idle, the threshold for such judgment can be increased with either the INI parameter IDLE=nnnn, or the operator command IDLE nnnn. If this condition is ongoing, then the INI file presents the most effective solution. If transient or when first noticed, the command provides an immediate remedy.
Default: The default is 45 seconds; increasing the value by multiples of 15 seconds is the most sensible approach. This value affects the timeout of certain command processes. Therefore, do not set the value higher than necessary, otherwise the command processor can be adversely affected.
Example: IDLE=45
Note: The IDLE parameter can be changed on each LPAR with a system console command. The syntax is as follows: xxIDLE=nnnn where xx is the user's CPFX value, and nnnn is the number of seconds. Note that the SET command is not used for this parameter.

MAXTRK

MAXTRK=n
Where n is a value 1 - 15.
Synopsis: This optional parameter specifies the size of I/O operation in tracks, that is, that the I/O copy operations of zDMF are to transfer less than a full cylinder of data. The MAXTRK value is used to reduce the application response time impact of zDMF Copy operations, immediately following Activation.
Example: MAXTRK=5 can cause zDMF to move a 15-track cylinder extent in 3 I/O operations. The time that the device is unavailable to application I/O operations is divided into three short windows, as opposed to a single, longer window.

SERVER_IPADDR

SERVER_IPADDR=(server_ip_address[,SMFID])
Default: Primary interface IP address¹, local SMFID. The primary interface IP address is defined on the PRIMARYINTERFACE statement (for IPv4) or the INTERFACE statement (for IPv6) in the TCPIP.DATA file. If the PRIMARYINTERFACE statement is not specified, the first address in the HOME list is the default local address. This default local address is a value that is obtained by the GETHOSTID( ) function. See the z/OS Communications Server IP Configuration Reference (SC31-8776) for details.
Synopsis: Allows specification of a TCP/IP IP address other than the primary interface IP address.
Note: The IP version of the IP address specified (or defaulted) on the SERVER_IPADDR and MULTICAST_IPADDR parameters must be the same. For example, if an IPv6 address is specified on the SERVER_IPADDR parameter, an IPv4 address cannot be specified on the MULTICAST_IPADDR parameter.
Specifying SERVER_IPADDR=(0) disables TCPIP processing in zDMF.
Server IP address syntax requirements:
- A fully qualified colon-hexadecimal format for IPv6, or a four node dot-decimal address for IPv4.
SMFID syntax requirements:
- Any valid MVS SMFID.

MULTICAST_IPADDR

MULTICAST_IPADDR=multicast_ip_address
Default: FF08::4:2024 (IPv6)
```
239.242.024.202 (IPv4)
```
Synopsis: Allows specification of a TCP/IP Multicast IP address with specific assignment, routing, or scoping characteristics. For reference, see the IPv4 Multicast Address Space Registry website (www.iana.org/assignments/multicast-addresses) and the IPv6 Multicast Address Space Registry website (www.iana.org/assignments/ipv6-multicast-addresses). These addresses provide organization-local scope that permits routing throughout the private network of an organization.
Packets cannot routed over the public internet. They must be encapsulated (such as in a VPN) if public routing is required. All zDMF servers that share a zDMF database must have the same MULTICAST_IPADDR parameter.

Note: The IP version of the IP address specified (or defaulted) on the SERVER_IPADDR and MULTICAST_IPADDR parameters must be the same. For example, if an IPv6 address is specified on the SERVER_IPADDR parameter, an IPv4 address cannot be specified on the MULTICAST_IPADDR parameter.
Syntax requirements:
- A fully qualified colon-hexadecimal format for IPv6, or a four node dot-decimal address for IPv4.

SERVER_HOSTNAME

SERVER_HOSTNAME=(server_hostname[,SMFID])
Default: Default processor host name², local SMFID. The default processor host name is defined on the HOSTNAME statement in the TCPIP.DATA file. This default name is obtained by the GETHOSTNAME( ) function. See the z/OS Communications Server IP Configuration Reference (SC31-8776) for details.
Synopsis: Allows specification of a TCP/IP host name other than the default host name. If the startup Configuration PDS member is shared by multiple zDMF servers, the SMFID specification associates the host name with a particular zDMF server.
Server host name syntax requirements:
- Maximum of 24 characters
- Must contain one or more tokens that are separated by a period
- Each token must be larger than one character
- First character in each token must start with a letter
- Remaining characters in each token must be a letter, number, or hyphen
SMFID syntax requirements:
- Any valid MVS SMFID.

SERVER_PORT

SERVER_PORT=port_number
Default=53135
Synopsis: Port number that is used for TCP/IP communications between zDMF servers. All zDMF servers that participate in a Migration Group must have the same SERVER_PORT value. A TCP port and a UDP port are allocated with this port number.
Syntax requirements:
- Any value 0 - 65535 can be used. Before you specify the port number for the SERVER_PORT parameter, consult the Systems Programmer responsible for port assignments for the Communications Server for z/OS.
- Your use of the Internet Assigned Numbers Authority (IANA) Dynamic or Private Ports in the range of 49152 to 65535 is highly advisable. Use of other ports can result in errors such as ERRNO 48 EADDRINUSE or unexpected data being received on the socket connection. See the Service Name and Transport Protocol Port Number Registry website (www.iana.org/assignments/port-numbers) for the official list of well-known port numbers.

CLIENT_TIMEOUT

CLIENT_TIMEOUT=timeout_seconds
Default=3
Synopsis: Maximum number of seconds that a TCP/IP client within an zDMF server waits to complete a network connection request to another zDMF server. If the connection request is not completed within in the allotted time, the connection request wait period ends and processing continues.
Syntax requirements:
- Minimum value: 1
- Maximum value: 600

SERVER_TIMEOUT

SERVER_TIMEOUT=timeout_seconds
Default=60
Synopsis: Maximum number of seconds that an zDMF server waits for a response to a TCP/IP message sent to another zDMF server. If a response it not received in the allotted time, the message wait ends and processing continues.
Syntax requirements:
- Minimum value: 1
- Maximum value: 600

TCPIP_ADDRSPC

TCPIP_ADDRSPC=tcpip_address_space_name
Default=Primary TCP/IP address space name
Synopsis: TCP/IP address space name or stack that is used by zDMF server TCP/IP functions.
Syntax requirements:
- Any valid MVS address space name.

SMFTYPE

SMFTYPE=(nnn[,TYPE(ss,ss,...)|,NOTYPE(ss,ss,...)])
Where:
- nnn is the SMF record type (also known as record number)
- ss is the SMF record subtype.
Synopsis:
Enables SMF data recording to the specified SMF record type and subtype numbers. zDMF creates event and interval SMF records. Interval recording is completed according to the SMFINT parameter.
- The second positional parameter TYPE is an optional list of record subtypes to be included. If this parameter is not specified, all subtypes are recorded, except 5, 6, 8 and 10.
- The other second positional parameter is NOTYPE. It is mutually exclusive with TYPE. This parameter is the list of subtypes to be excluded from recording. If this parameter is not specified, all subtypes are recorded except 5, 6, 8 and 10.
The TYPE and NOTYPE subparameters have no effect if SMFTYPE is not specified.
SMFTYPE syntax requirements:
- Any integer 128 - 255. Specify a record type that is not currently in use by another product.
TYPE and NOTYPE syntax requirements:
- Any integer 1 - 21. Up to 21 values can be listed in a comma-delimited list. If a value is repeated, no error message is produced.
Default:
- None for SMFTYPE; SMF recording is disabled.
- TYPE defaults to 1, 2, 3, 4, 7, 9, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21.
- NOTYPE defaults to 5, 6, 8, 10 meaning these subtypes are not recorded.
Example:
- SMFTYPE=(230,NOTYPE(6,7,9,10)). All subtypes except 6, 7, 9, and 10.

SMFINT

SMFINT=nnnn
Where nnnn is a value 0 - 1440.
Synopsis:
Specifies the number of minutes between SMF interval data recording. If 0 is specified, interval recording is disabled, and event recording is unaffected.
Default: Default is 5. zDMF creates SMF interval records every 5 minutes. This parameter has no effect if SMFTYPE is not specified.
Example: SMFINT=7. Interval records every 7 minutes.

UNIDENTIFIED_SYSTEMS_ACTION

UNIDENTIFIED_SYSTEMS_ACTION=(IGNORE|WARNing|TERMinate[,SMFID])
Synopsis:
Tells zDMF to check that a zDMF server is active on all z/OS images that can access a shared migration volume on a standard 3990-6 compatible control unit:
- IGNORE causes no action
- WARNing results in warning messages (GZD4192W or GZD4194W)
- TERMinate causes the group activation to fail if not all z/OS images with access to the source volume have an active zDMF server. The failure message is GZD4191E or GZD4193E. If a target volume fails the check, it is removed from candidacy, message GZD4195I displays, and the activation continues while other target volumes are available.
  If the startup Configuration PDS member is shared by multiple zDMF servers, the SMFID specification associates the Action with a particular zDMF server.
  
  Note: You are advised to initially run in TERMinate mode to verify correct operations and build an IGNORE_SYSTEMS list if needed.
Default: TERMinate,local SMFID
SMFID Syntax Requirements:
- Any valid MVS SMFID.

IGNORE_SYSTEMS

IGNORE_SYSTEMS=(cpuid1,cpuid2,...,cpuid128[,SMFID])
Synopsis:
Specifies a list of up to 128 ten-digit hexadecimal serial numbers (CPUIDs) that are not to be considered when the UNIDENTIFIED_SYSTEMS_ACTION checks are processed. This list is used if residual logical path data in the controller memory is causing activations to fail with message GZD4191E.

If the startup Configuration PDS member is shared by multiple zDMF servers, the SMFID specification associates the Action with a particular zDMF server. SMFID must follow the last CPU serial number.
Default: None.
SMFID Syntax Requirements:
- Any valid MVS SMFID.

ZHPFIO

ZHPFIO=YES|NO
Synopsis:
Specifies whether support for I/O channel programs using High Performance FICON for System z (ZHPF) is active (YES) or not active (NO).

When YES is specified, the ZHPF I/O monitor intercepts ZHPF I/O channel programs from a source device and mirrors the ZHPF I/O channel program to the target device if the target device supports ZHPF. If the target device does not support ZHPF, the target I/O channel program is translated to a standard legacy ECKD channel program.

If ZHPFIO=NO is specified, ZHPF channel programs are converted to legacy ECKD channel programs for both source and target devices.
Default: YES

AUTO_REACTIVATE

AUTO_REACTIVATE=YES|NO
Synopsis:
If during a migration a participating system was IPLed, source data sets might have been modified before zDMF on that system regained control. The migration cannot be continued and groups in any pre-divert state are deactivated. With AUTO_REACTIVATE=YES it is possible to automatically reactivate those groups. Omitting the parameter or specifying NO will leave those groups deactivated. The user may then manually activate them at a later time.
Syntax requirements: YES or NO
Default: NO

ALLOW_ENCRYPT_BYPASS_SAF

ALLOW_ENCYRPT_BYPASS_SAF=YES|NO
Specifying ALLOW_ENCRYPT_BYPASS_SAF=YES allows zDMF to bypass SAF security checking for encryption labels.
This bypasses CSFKEYS/keylabel name profile checking but not any required FACILITY CLASS checking required for DFSMS.
Default: NO

INIT PARM EMCS_RACF_USERID

INIT PARM EMCS_RACF_USERID=YES|NO
This parameter determines if users of the EMCS console will have their user ID presented to the zDMF SAF exit GZDXSAF
Specifying INIT PARM EMCS_RACF_USERID=YES will verify EMCS console input.
Default: NO

BASIC_LARGE_ENCRYPTION

BASIC_LARGE_ENCRYPTION=YES|NO
This parameter is used when the group should encrypt basic and large data sets. It is mutually exclusive with ENCRYPTION(YES), ROTATE(YES), and CONVERT_TO_EXTENDED_FORMAT(YES). All data sets in the group must be in the Basic or Large format and be eligible to be encrypted.
The TOLERATE_SOURCE_VALIDATE_FAILURE(YES) definition parameter will allow a group with data sets that are eligible for basic and large data set encryption to proceed by skipping any data sets that cannot be encrypted.
The RACF CLASS(FACILITY) PROFILE(STGADMIN.SMS.ALLOW.DATASET.SEQ.ENCRYPT) must be available to the zDMF server to allow any encryption to proceed.
The zDMF server must have access to the CSFKEYS profile that controls any keys being used for a zDMF group. The ALLOW_ENCRYPT_BYPASS_SAF zDMF initialization parameter must be set to YES.
Standard IBM encryption of basic and large data sets adds an 8 byte prefix to each block of a data set. This additional 8 byte addition will prevent some blocksizes from being encrypted by zDMF as it cannot change the number of blocks on a track when encrypting. These data set will be identified by message GZD4230, and the affected data set will be skipped or the group will terminate depending on your TOLERATE_SOURCE_VALIDATE_FAILURE setting.
The KEYLABEL used for encryption is determined in the same order as extended format data set encryption. The SAF compliant security product is first searched, followed by the zDMF control cards KEYLABEL parameter. Finally, the SMS data class is searched. If no KEYLABEL is found the data set is skipped or the group is terminated depending upon the TOLERATE_SOURCE_VALIDATE_FAILURE setting. For more information refer to data set encryption.

MIN_FREE_ECSA%

MIN_FREE_ECSA%=percentage

• Default=10

• Synopsis: When activating a migration group, zDMF verifies that it does not cause excessive usage of CSA storage. If activation would cause the remaining amount of CSA to fall below the specified percentage of total CSA space (or if it already is), then the activation fails. In general, this option is intended to allow the minimum to be lowered in certain cases where a large CSA allocation is highly committed, and requiring 10% free is not feasible. zDMF can only control its own CSA usage. It cannot guarantee that the free space does not change as it goes through its processing.

• Syntax: Minimum is 0, maximum is 80.

ALLOW_DIVERT_WHILE_OPEN={YES|NO}

When set to NO, zDMF does not allow a migration group to move into Divert status if any of its data sets are open. This is the same behavior as can currently occur in certain other conditions.
When set to YES (or defaulted), divert while open occurs just the same as existing behavior. YES is the default.

¹ The primary interface IP address is defined on the PRIMARYINTERFACE statement (for IPv4) or the INTERFACE statement (for IPv6) in the TCPIP.DATA file. If the PRIMARYINTERFACE statement is not specified, the first address in the HOME list is the default local address. This default local address is a value that is obtained by the GETHOSTID() function. See the z/OS Communications Server IP Configuration Reference (SC31-8776) for details.

² The default processor host name is defined on the HOSTNAME statement in the TCPIP.DATA file. This default name is obtained by the GETHOSTNAME( ) function. See the z/OS Communications Server IP Configuration Reference (SC31-8776) for details.