devices. With z/OS and the zSeries, paths may be dynami- cally assigned to control units to refl ect the I/O load. For example, in an environment where an installation normally requires four channels to several control units, but occa- sionally needs as many as six, system programmers must currently defi ne all six channels to each control unit that may require them. With Dynamic Channel Path Manage- ment (DCM), the system programmer need only defi ne the four channels to the control units, and indicate that DCM may add an additional two. As the control unit becomes more heavily used, DCM may assign channels from a pool of managed channels, identifi ed by the system program- mer, to the control unit. If the work shifts to other control units, DCM will unassign them from lesser utilized control units and assign them to what are now the more heavily used ones. DCM is for ESCON and FICON Bridge chan- nels can help reduce the number of channels required to effectively run a workload. DCM can also help reduce the cost of the fi ber infrastructure required for connectivity between multiple data centers. On a z890/z990 with Logi- cal Channel SubSystems (LCSSs), the scope of DCM man- agement is within a Logical Channel SubSystem. Although an LPAR cluster can span LCSSs, when DCM is used it will only consider systems in the same LPAR cluster and the same LCSS.
Channel Subsystem Priority Queuing
The notion of I/O Priority Queuing is not new; it has been in place in OS/390 for many years. With IRD, this capability is extended into the I/O channel subsystem. Now, when higher priority workloads are running in an LPAR cluster, their I/Os will be given higher priority and will be sent to the attached I/O devices (normally disk but also tape and network devices) ahead of I/O for lower priority workloads. LPAR priorities are managed by WLM in goal mode.
Channel Subsystem Priority Queuing provides two advan- tages. First, customers who did not share I/O connectivity via MIF (Multiple Image Facility) out of concern that a lower priority I/O intensive workload might preempt the I/O of higher priority workloads, can now share the channels and reduce costs. Second, high priority workloads may even benefi t with improved performance if there were I/O contention with lower priority workloads. Initially, Channel Subsystem Priority Queuing is implemented for Parallel OEMI and ESCON, FICON Bridge and native FICON channels.
On a z890/z990, the scope of Channel Subsystem I/O Priority Queuing is a Logical Channel SubSystem.
Channel Subsystem Priority Queuing complements the IBM Enterprise Storage Server capability to manage I/O priority across CECs.
With IRD, the combination of z/OS and zSeries working in synergy extends the
Parallel Sysplex Professional Services
IBM provides extensive services to assist customers with migrating their environments and applications to benefi t from Parallel Sysplex clustering. A basic set of IBM services is designed to help address planning and early implementation requirements. These services can help you reduce the time and costs of planning a Parallel Sysplex environment and moving it into production. An advanced optional package of services is also available and includes data sharing application enablement, project management and business consultation through advanced
47