Coupling Facility Control Code (CFCC) Level 19 exploitation of the Flash Express feature is designed to help improve resiliency while providing cost-effective standby capacity to help handle the overflow of WebSphere MQ shared queues. You can now specify overflow areas for certain Coupling Facility list structures in the Storage Class Memory (SCM) provided by the Flash Express feature. This is designed to allow structure data to be migrated to Flash Express memory as needed and migrated back to real memory to be processed. When using WebSphere MQ for z/OS Version 7 (5655-R36), this new capability is expected to help provide significant buffering against enterprise messaging workload spikes and to help provide support for storing very large amounts of data in shared queue structures, potentially allowing several hours of data to be stored without causing interruptions in processing.
CFCC Level 19 exploitation of the Flash Express feature (#0402) on zEC12 and zBC12 Coupling Facilities requires the following:
Software requirements with availability in the first half of 2014:
CFSizer has been updated with support for CFCC Level 19 exploitation of the Flash Express feature. The following are now available:
XCF and XES are designed to allow the use of shared engine coupling facilities in many production environments with improved performance. This is intended to allow Parallel Sysplex to be implemented at lower cost in many environments by reducing the number of environments for which dedicated coupling facility (CF) engines are needed to achieve good performance. In addition, a new set of interrupts provided on zEC12 servers with CFLEVEL 19 and a minimum MCL is designed to be used by z/OS to help reduce XCF and XES processing overhead and improve performance when processing asynchronous coupling facility operations and recognizing certain CF events.
XCF provides a simplified set of interfaces for passing messages within a Parallel Sysplex. New services are designed to allow a server to be established to process messages and to send messages across the sysplex without first joining an XCF group. This is intended to make it easier to exploit XCF services for applications that do not require the member management and monitoring provided by the XCF group services interfaces.
The RMF Postprocessor Coupling Facility Activity and the Monitor III CFSYS report can be used to monitor resources associated with the Coupling Facility and CF links. They both have now been extended to indicate channel path details for each of the Coupling over InfiniBand (CIB) link types. This information can help with monitoring and tuning of the Parallel Sysplex.
Removal of "Sick but not dead" systems that have defined themselves as a "Critical Member". This is intended to help reduce the incidence of sysplex-wide problems that can result from unresponsive critical components. GRS is planned to exploit these XCF critical member functions in both ring and star modes. Additionally, GRS will be designed to monitor key tasks and notify XCF if it detects that GRS is impaired.
New CFSTRHANGTIME keyword to allow a structure to be in "hang" condition before corrective action is taken (Stop rebuild, disconnect or terminate connector). This helps avoid sysplex-wide problems that can result from a CF structure that is waiting for timely responses from CF structure connectors.
Improved time it takes for the second and subsequent systems to join a Parallel Sysplex.
New "Display XCF,REALLOCATE" command to report on progress of reallocates
Improved Parallel Sysplex availability with non-disruptive CF dumping capability. z/OS V1.12, in conjunction with z196 servers and Coupling Facility control code (CFCC) Level 17, is designed to capture Coupling Facility (CF) data nondisruptively in some circumstances, allowing the CF to continue operating. The CF uses a pre-staged dump capture area to avoid collateral effects observable by z/OS, such as message time-outs (observed as interface control checks) or loss of connectivity.
The AutoIPL support introduced in z/OS V1.10 is extended to multisystem-capable sysplex configurations with active Sysplex Failure Management (SFM) policies in z/OS in a sysplex.
The sysplex failure management (SFM) is designed to use new Base Control Program internal interface (BCPii) services to determine whether an unresponsive system has failed, expedite sysplex recovery by bypassing delay intervals when possible, and automatically reset failed systems without manual intervention. This new function allows SFM to avoid waiting for a period of time before assuming that systems have failed, improve the responsiveness of failure management, avoid operator intervention, and help limit or avoid sysplex-wide slowdowns that can result from single-system failures.
XCF FDI Consistency enforces consistency between the system Failure Detection Interval (FDI) and the excessive spin parameters. This allows system to perform full range of spin recovery actions before it gets removed from the sysplex and avoids false removal of system for a recoverable situation. Also, a new way to specify an operator notification (OPTNOTIFY) relative to the effective FDI is provided, so that you no longer need to calculate the sum of spin loop timeouts to specify the operator notification interval.
With z/OS 1.11, the system default action is ISOLATETIME(0), changed from PROMPT
Refer to the following U.S. Announcement Letters:
For all announcement letters and geographies, refer to the IBM Offering Information website.
Removal of support for the HCA2-O fanouts for 12x IFB and 1x IFB InfiniBand Coupling Links: The IBM zEnterprise EC12 and the IBM zEnterprise BC12 are planned to be the last System z servers to support the following features as carry forward on an upgrade: HCA2-O fanout for 12x IFB coupling links (#0163) and HCA2-O LR fanout for 1x IFB coupling links (#0168). Enterprises should continue migrating to the HCA3-O fanout for 12x IFB (#0171) and the HCA3-O LR fanout for 1x IFB (#0170).
Removal of ISC-3 support on System z: The IBM zEnterprise EC12 and the IBM zEnterprise BC12 are planned to be the last System z servers to offer support of the InterSystem Channel-3 (ISC-3) for Parallel Sysplex environments at extended distances. ISC-3 will not be supported on future System z servers as carry forward on an upgrade. Previously we announced that the IBM zEnterprise 196 (z196) and IBM zEnterprise 114 (z114) servers were the last to offer ordering of ISC-3. Enterprises should continue migrating from ISC-3 features (#0217, #0218, #0219) to 12x InfiniBand (#0171 - HCA3-O fanout) or 1x InfiniBand (#0170 - HCA3-O LR fanout) coupling links.
Removal of support for connections to an STP Mixed CTN: The IBM zEnterprise EC12 and the IBM zEnterprise BC12 are the last System z servers to support connections to an STP Mixed CTN. This includes the Sysplex Timer (9037). After the zEC12 and the zEnterprise BC12, servers that require Time synchronization, such as to support a base or Parallel Sysplex, will Require Server Time Protocol (STP), and all servers in that network must be configured in STP-only mode.