Migration and exploitation considerations for z196 and z114 server functions

This topic provides migration and exploitation considerations for zEnterprise server functions.

The following zEnterprise functions are available on z/OS V1R12 and later releases:

InfiniBand Coupling. Each system can use, or not use, InfiniBand coupling links independently of what other systems are doing, and do so in conjunction with other link types. InfiniBand Coupling connectivity can only be performed with other systems that also support InfiniBand Coupling.
HiperDispatch. The existing HIPERDISPATCH=YES|NO parameter in IEAOPTxx member of parmlib, and on the SET OPT=xx command to control whether HiperDispatch is enabled or disabled for the system, can be changed dynamically.
A WLM goal adjustment might be required when using HiperDispatch. Review and update your WLM policies as necessary.
HiperDispatch cache and affinity node changes. This function is enhanced to exploit zEnterprise architecture and now allows three physical CPs from same chip to form affinity node. A z10™ uses HiperDispatch book cache support and four physical CPs from same book.
To realize the benefits of HiperDispatch, z/OS has been changed to force HiperDispatch=YES for LPARs with greater than 64 CPUs. On LPARs with greater than 64 CPUs defined on a zEnterprise server with IEAOPTxx specifying HIPERDISPATCH=NO during IPL (or SET OPT=xx after IPL), the system generates a message but continues to run with HIPERDISPATCH=YES. The new message is IRA865I HIPERDISPATCH=YES FORCED DUE TO GREATER THAN 64 LPS DEFINED.

On LPARs in which HIPERDISPATCH=NO is specified with less than 64 CPUs, you can dynamically add more CPUs and continue to run in HIPERDISPATCH=NO. However, you may see the new message ISN012E HIPERDISPATCH MUST BE ENABLED TO CONFIGURE CPU IDS GREATER THAN 3F ONLINE.

Any attempt to configure CPUs greater than 64 CPUs online in HIPERDISPATCH=NO will be rejected with message IEE241I CPU(x) NOT RECONFIGURED ONLINE - REQUIRES HIPERDISPATCH ENABLED.

An LPAR with greater than 64 CPUs that dynamically changed to HIPERDISPATCH=YES cannot go back to HIPERDISPATCH=NO. It will be treated as if it was IPLed with HIPERDISPATCH=YES after HIPERDISPATCH=YES is activated.
To assist with warning when you are getting close to 64 CPUs and running with HIPERDISPATCH=NO, the IBM® Health Checker for z/OS® check, SUP_HiperDispatchCPUConfig, was added in z/OS V1R12. The check always succeeds for LPAR in HIPERDISPATCH=YES (all CPU configurations supported). When an LPAR is running with HIPERDISPATCH=NO, the check raises an exception when the number of CPUs is close to forcing the LPAR to IPL with HIPERDISPATCH=YES. The CPUSLEFTB4NEEDHD parameter indicates the minimum number of CPUs that can be installed and activated on an LPAR running in HIPERDISPATCH=NO. When CPUSLEFTB4NEEDHD=0, the check always succeeds. The default is 8, with values 0-63 accepted. To assist with warning when you are getting close to 64 CPUs and running with HIPERDISPATCH=NO, use IBM Health Checker for z/OS check, SUP_HiperDispatchCPUConfig. Possible IBM Health Checker for z/OS messages::
- IEAVEH080I CPU configuration supported with HiperDispatch curstate
- IEAVEH081E CPU configuration supported with HiperDispatch disabled. numcpus more CPU(s) can be added with HiperDispatch disabled.
CFCC Level 17. If you are moving your coupling facilities and the coupling facility structures will be on higher CFCC levels than they were previously, run the Coupling Facility Structure Sizer (CFSIZER) tool to find out if you have to increase coupling facility structure sizes. zEnterprise servers initially shipped with CFCC Level 17. Prepare to make the necessary changes as indicated by the tool. You can find the CFSIZER tool at Coupling Facility sizer.
Note: The PTFs to support CFCC Level 17 have coexistence (or sysplex preconditioning) PTFs that require installation throughout your sysplex before implementing CFCC Level 17.
Third Subchannel Set. You now have the ability to extend the amount of addressable storage capacity to help facilitate storage growth with the introduction of a third subchannel set, an additional 64K devices, to help complement other functions such as "large" or extended addressing volumes and HyperPAV. This may also help to facilitate consistent device address definitions, simplifying addressing schemes for congruous devices.
The first subchannel set (SS 0) allows definitions of any type of device, such as bases, aliases, secondaries, and those other than disk that do not implement the concept of associated aliases or secondaries. The second and third subchannel sets (SS1 and SS2) can now both be designated for use for disk alias devices (of both primary and secondary devices), or Metro Mirror secondary devices only. The third subchannel set applies ESCON, FICON® and zHPF protocols. Definitions for the third subchannel set are similar to those for the second subchannel set and can be made with HCD.

The IODF statement of LOADxx allows users to indicate which devices to use during IPL (that is, devices that are connected to subchannel set 0, 1 or 2). This specification is done on the IODF statement (column 36). For more information, see z/OS MVS Initialization and Tuning Reference.
IPL from alternate subchannel set. This function allows you to IPL from subchannel set 1 (SS1) or subchannel set 2 (SS2), in addition to subchannel set 0. Devices used early during IPL processing can now be accessed using subchannel set 1 or subchannel set 2. This is intended to allow users of Metro Mirror (PPRC) secondary devices defined using the same device number and a new device type in an alternate subchannel set to be used for IPL, IODF, and standalone dump volumes when needed. IPL from an alternate subchannel set is supported by z/OS V1R13 and V2R1, as well as z/OS V1R12 with PTFs, and applies to the FICON and zHPF protocols (CHPID type FC).
To IPL from an alternate subchannel set, you need to specify a 5 digit load address on the LPAR image profile on the HMC, and have the appropriate specification on the IODF statement column 36 in LOADxx. This capability is available for z196 as of September 2011 (GA2) and later and for z114. z114 supports only SS0 and SS1, so you cannot IPL from subchannel set 2 (SS2).

Tip: Column 36 of the IODF statement in LOADxx is the subchannel set indicator. This field indicates which subchannel set should be used as the primary volume during IPL. You can now specify an asterisk "*" for this value in the field to indicate that the subchannel set of the IPL volume should be used as the subchannel set for the primary volumes. APAR OA35135 for z/OS V1R11 and V1R12 added this new function to specify a asterisk "*" in column 36 of the IODF statement in LOADxx parmlib member.
IBM zEnterprise Unified Resource Manager for enabling management and virtualization of heterogeneous workloads. The Unified Resource Manager manages the deployment of heterogeneous hardware resources based on individual workload requirements:
- Performance management
- Integrated private data network
See System z® Ensemble Planning and Configuration Guide (GC27-2608) for a detailed description on the steps required.
Power save mode. This function is available only on z196 servers. There is a new SMFPRMxx parmlib option, MAXEVENTINTRECS, that allows governing the number of event interval records to be collected when the processor capacity changes. The default is zero. This function is available only on z196 servers; it is not available on z114 servers.
If you are using the CPU Measurement Facility (Hardware Instrumentation Services), there is a new parameter on the MODIFY hisproc command. You can use this parameter, STATECHANGE, to override the default action to take when a CPU speed change is detected within the HIS component.
zHPF performance improvements for FICON Express8S. FICON Express8S contains a new IBM ASIC which is designed to support the 8 Gbps (gigabytes per second) PCIe interface to the PCIe I/O drawer and increased start I/Os. In addition, a hardware data router has been added in support of the zHPF and FCP protocols for path length reduction and increased throughput. FICON Express8S supports a link data rate of 2, 4, or 8 Gbps autonegotiated. With these changes FICON Express8S, when supporting the zHPF or FCP protocols, has been designed to achieve full duplex line speed (8 Gbps) in each direction. The performance of the FICON protocol remains unchanged from FICON Express8. To use zHPF performance improvements for FICON Express8S, you need to specify the ZHPF=YES | NO parameter in the IECIOSxx of PARMLIB and use FICON Express8S.
Additional Crypto exploitation. The following enhancements have been added to the Common Cryptographic Architecture support, which is used in the Crypto Express3 feature when it is configured as a coprocessor:
- ANSI X9.8 Pin security
- Enhanced Common Cryptographic Architecture (CCA), 64bit, CP Assist for Cryptographic Function (CPACF) enhancements
- Secure Keyed-Hash Message Authentication Code (HMAC)
- CKDS Constraint Relief
- PCI Audit, Elliptical Curve Cryptography (ECC) Digital Signature Algorithm
- CBC Key Wrap
- PKA RSA OEAP with SHA-256
- Expanded support for AES algorithm
- Enhanced ANSI TR-31 Secure Key Exchange
- PIN block decimalization table protection
- PKA RSA OAEP with SHA-256 algorithm, additional Elliptic Curve Cryptography (ECC) functions.
z/OS Discovery and AutoConfiguration (zDAC) for FICON channels. With a zEnterprise CPC and z/OS, a new function, z/OS Discovery and AutoConfiguration (zDAC), is designed to automatically perform a number of I/O configuration definition tasks for new and changed disk and tape controllers through FICON channels. Starting with z/OS V2R1 FICON point-to-point paths are also included in the discovery process whether or not they are connected to a switch or director when attached to a FICON channel. When new controllers are added to an I/O configuration, or changes are made to existing controllers, the system is designed to discover them and propose configuration changes based on a policy you define in the Hardware Configuration Definition (HCD) dialog. Your policy can include preferences for availability and bandwidth including parallel access volume (PAV) definitions, control unit numbers, and device number ranges.
zDAC is designed to perform discovery for all systems in a sysplex that support the function. The proposed configuration will incorporate the current contents of the I/O definition file (IODF) with additions for newly installed and changed control units and devices. zDAC is designed to help simplify I/O configuration on CPC running z/OS and reduce complexity and setup time. zDAC applies to all FICON features supported on zEnterprise servers when configured as CHPID type FC, and is supported by z/OS V1R12 and later.

To use zDAC, you must first establish a policy for the discovery operation. This is done through HCD or HCM. You can limit the scope of the discovery, limit the proposal information, indicate the desired number of paths to discovered logical control units, and indicate the method used for device and control unit numbering. After controllers and devices are discovered, you can select which controllers to be defined and accept or override the proposed values for control units and devices.
OSA-Express3 and OSA-Express4S Inbound Workload Queuing (IWQ). Inbound workload queuing for Enterprise Extender is supported by the OSA-Express4S and OSA-Express3 features when defined as CHPID types OSD or OSX. It is exclusive to the z196 and z114 servers, and is supported by z/OS and by z/VM for guest exploitation. OSA-Express3 introduces inbound workload queuing (IWQ), which creates multiple input queues and allows OSA to differentiate workloads "off the wire" and then assign work to a specific input queue (per device) to z/OS. With each input queue representing a unique type of workload, each having unique service and processing requirements, the IWQ function allows z/OS to preassign the appropriate processing resources for each input queue. This approach allows multiple concurrent z/OS processing threads to then process each unique input queue (workload), avoiding traditional resource contention. In a heavily mixed workload environment, this "off the wire" network traffic separation provided by OSA-Express3 IWQ reduces the conventional z/OS processing required to identify and separate unique workloads, which results in improved overall system performance and scalability. The types of z/OS workloads that are identified and assigned to unique input queues are:
- z/OS Sysplex Distributor traffic: Network traffic that is associated with a distributed Virtual Internet Protocol Address (VIPA) is assigned a unique input queue allowing the Sysplex Distributor traffic to be immediately distributed to the target host.
- z/OS bulk data traffic: Network traffic that is dynamically associated with a streaming (bulk data) TCP connection is assigned to a unique input queue allowing the bulk data processing to be assigned the appropriate resources and isolated from critical interactive workloads.
IWQ is supported on zEnterprise CPC and System z10, and is exclusive to OSA-Express3 CHPID types OSD and OSX (exclusive to zEnterprise CPC). There are some Communications Server configuration settings required to enable multiple inbound data queues.
Display OSAINFO. OSA-Express3 introduces the capability for the operating system to directly query and display the current OSA configuration information (similar to OSA/SF). z/OS exploits this new OSA capability by introducing a new TCP/IP operator command, Display OSAINFO. Display OSAINFO allows the operator to monitor and verify the current OSA configuration, which helps to improve the overall management, serviceability, and usability of OSA-Express3. The Display OSAINFO command is exclusive to OSA-Express3 CHPID types OSD, OSM, and OSX (on z196, z114, and z10 servers).
XL C/C++ ARCH(9) and TUNE(9) options. The ARCHITECTURE XL C/C++ compiler option selects the minimum level of machine architecture on which your program can run. Certain features provided by the compiler require a minimum architecture level. ARCH(9) exploits instructions available on zEnterprise servers. For more information, refer to the ARCHITECTURE compiler option in z/OS XL C/C++ User's Guide. The TUNE compiler option allows you to optimize your application for specific machine architecture. The TUNE level has to be at the ARCH level, at a minimum. If the TUNE level is lower than the specified ARCH level, the compiler forces TUNE to match the ARCH level, or uses the default TUNE level, whichever is greater. For more information about the ARCHITECTURE and TUNE compiler options refer to z/OS XL C/C++ User's Guide.
Exploitation restriction. When programs exploit the ARCH(9) or TUNE(9) option, those programs can only run on zEnterprise servers, or an operation exception will occur. This is a consideration for programs that will run on different server levels (z10 and z9® servers) during development, test, and production, as well as during fallback or disaster recovery.

The following zEnterprise functions are only available on z/OS V1R13 and later releases. See z/OS Introduction and Release Guide for restrictions, dependencies, and steps to take to use these new hardware functions:

OSA-Express4S checksum offload for LPAR-to-LPAR traffic for IPv4 and IPv6 packets (CHPID type OSD). Checksum offload for LPAR-to-LPAR traffic is included in the OSA-Express4S design. The checksum function has been moved from the PCIe adapter to the OSA-Express4S hardware to help reduce CPU utilization.
OSA-Express4S large send for IPv6 packets (CHPID types OSD and OSX). Large send (also referred to as TCP segmentation offload) is designed to improve performance by offloading outbound TCP segmentation processing from the host to an OSA-Express4S feature by employing a more efficient memory transfer into OSA-Express4. Large send support for IPv6 packets applies to the OSA-Express4S features (CHPID type OSD and OSX), and is exclusive to z196 and z114.
Inbound workload queuing for Enterprise Extender. Inbound workload queuing (IWQ) for the OSA-Express4S features has been enhanced to differentiate and separate inbound Enterprise Extender traffic to a new input queue. The Enterprise Extender separation and processing associated with the Enterprise Extender input queue provides improved scalability and performance for Enterprise Extender.

Note: See z/OS V2R1.0 Communications Server: IP Configuration Guide for additional information about OSA-Express4S checksum offload for LPAR-to-LPAR traffic for IPv4 and IPv6 packets (CHPID type OSD), OSA-Express4S large send for IPv6 packets (CHPID types OSD and OSX), and Inbound workload queuing for Enterprise Extender.