Prerequisites and operational considerations for using I/O Autoconfiguration

Consider the following information when exploiting the I/O Autoconfiguration functionality of HCD:

• The I/O Autoconfiguration process requires that the systems in the partitions from the LP groups are running on a zEnterprise 196 (z196) processor with at least z/OS V1R12.
• The target work IODF should be equal to, or be a descendent of the active IODF. This restriction is not enforced but recommended to facilitate consistent discovery of devices. If devices need to be added to do discovery, failures may occur due to inconsistent IODFs. Hardware definitions of this active IODF will remain consistent.
• All active IODFs for the systems in a SYSPLEX should be the same. This restriction is not enforced, but allows HCD to optimize the discovery process for the different systems by reusing the defined configuration. Tokens should be in sync, prior activates should have been completed.
• Without indicating Force full mode discovery, there is a limit on the number of subsequent failures. Unless force full mode discovery is requested, processing assumes that CUADD values start at 00 and continue to the last defined value in consecutive order, with no missing CUADDs.
• For DASD controllers, all newly discovered devices are assumed to be 3390 type devices, either type 3390A or 3390B.
• Switches may have port restrictions via zoning or via using a switch matrix, that limit the ability of a CHPID to connect to a destination port of a control unit interface. If such port restrictions exist within a switch, I/O Autoconfiguration may configure paths that cannot be used. If a port is discovered on a controller, it is assumed that it has access to all configured logical control units on that controller.
• Only accessible CHPIDs, switches, and ports that are configured online are considerd during discovery.
• At least one system per CPC must have the ability to perform dynamic I/O configuration changes. This system needs not be part of the target LP group.
• A logical control unit containing only secondary devices in an active PPRC relationship may not be able to be discovered. The I/O processing used to determine the devices configured on a logical control unit cannot be performed on secondary devices.
• I/O Autoconfiguration is a configuration tool that configures for availability. You can use Dynamic CHPID Management (DCM) for performance management. CHPID and path selection of I/O Autoconfiguration minimizes or even eliminates single points of failure for newly discovered logical control units. DCM manages the performance by adding CHPIDs and paths to the logical control units as needed.
• Within a target LP group, I/O Autoconfiguration proposes definitions only for controllers that are consistently defined or absent for the target LP group systems in the base IODF. If a controller is partially defined in the LP group, meaning that some systems have logical control units and devices configured that others do not have, I/O Autoconfiguration does not propose definitions for the systems within the LP group that do not have the control units. In such a situation, you can control the target discovery scope using LP groups that contain only systems which require the definition.
• If candidate access lists currently exclude an LPAR from accessing a control unit already defined on a CSS, I/O Autoconfiguration does not discover and add that control unit. Therefore, it is recommended that all systems in the participating LP groups should have a homogeneous view of the devices and control units. If this is not the case, you can update device candidate lists in HCD to add devices and control units to the desired LPARs before you start I/O Autoconfiguration.
• If switches are connected such that it would be possible to have three or more switches in a path to a control unit, it is possible that this path would be chosen if no viable alternative exists.
• HCD requires that either all or none of the switches and ports in the path from the CHPID to the control unit are defined in the target IODF. Otherwise, path validation may report errors.
• Discovery attempts should be performed during times where changes are minimal. ACTIVATE processing and CF CHP commands may affect discovery processing and should be avoided as far as possible.
• I/O Autoconfiguration can write diagnostic messages to the SYSLOG to help understand the processing decisions. To enable this, add the TRAPS NAME(IOSZDACMSGS) statement to the DIAGxx member that is currently in use and then issue the SET DIAG=xx command to refresh the current settings. See z/OS MVS Initialization and Tuning Referencez/OS MVS Initialization and Tuning Reference for information on the TRAPS NAME() keyword.
• When performing autoconfiguration for a processor, consider including LPARs on all CSSs on the processors in the discovery scope (using the AUTO_SUG_LPGROUP option). Note that if only a single CSS is requested in the scope of the discovery and autoconfiguration option, subsequent attempts to discover and autoconfigure on other CSSs for that same processor may experience resources exceeded conditions when spanned CHPIDs are in use. If the discovery must use the scope of a single CSS, discovered control units and devices may need to be manually copied to the other CSSs using HCD panels.
• Several devices are required for the discovery process. The active configuration must have devices available for discovery for all target systems. Requirements include a free range of 256 consecutive device numbers to be used for disk exploration, a free range of 16 consecutive device numbers to be used for tape exploration, and another single free device to be used to explore the fabric for controllers.
• During a discovery process, avoid removing or adding systems to the sysplex. This could cause the active discovery attempt to fail. If you need to IPL or remove a system in the sysplex, you can exit the I/O Autoconfiguration process and resume it once the systems have been IPLed or removed.
• If a discovery would produce a proposal containing a two-byte link address for a control unit, hinting to a switch connection for this control unit, but no switch definition is found in the IODF, then the proposal fails. HCD issues a message containing the missing switch address. Users must now first define the switch using the reported switch address and then repeat the discovery. HCD then performs the control unit’s connection to the switch automatically.
• If a proposal for a control unit contains a switch port that is defined as uninstalled or occupied in the IODF, HCD automatically changes the switch port to either installed or not occupied and then defines the connection.
• When a mixture of switched and directly attached paths to a control unit are found, path proposal processing only creates a set of all switched paths or all directly attached paths. Path proposal processing favors directly attached paths over switched paths in most cases, except for when a set of switched paths can satisfy the number of requested static paths when not enough directly attached paths are available for proposal.