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 world-class workload management tradition of S/390 and OS/390 so that the most important work on a server meets its goals, to increase the effi ciency of existing hardware, and to reduce the amount of inter- vention in a constantly changing environment.

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

Page 47
Image 47
IBM 890 manual Channel Subsystem Priority Queuing, Parallel Sysplex Professional Services