Benefits of Parallel Sysplex: Dynamic

The entire Parallel Sysplex® cluster can be viewed as a single logical resource to end users and business applications. Just as work can be dynamically distributed across the individual processors within a single SMP server, so too, can work be directed to any node in a Parallel Sysplex cluster having available capacity. This capability avoids the need to partition data or applications among individual nodes in the cluster or to replicate databases across multiple servers.

Workload balancing also permits a business to run diverse applications across a Parallel Sysplex cluster while maintaining the response levels critical to a business. The mainframe IT director selects the service level agreements required for each workload, and the workload management (WLM) component of z/OS®, along with subsystems such as CP/SM or IMS™, automatically balances tasks across all the resources of the Parallel Sysplex cluster to meet these business goals. The work can come from a variety of sources, such as batch, SNA, TCP/IP, DRDA®, or WebSphere® MQ.

There are several aspects to consider for recovery:

First, when a failure occurs, it is important to bypass it by automatically redistributing the workload to utilize the remaining available resources.
After the failing element has been isolated, it is necessary to non-disruptively redirect the workload to the remaining available resources in the Parallel Sysplex. In the event of failure in the Parallel Sysplex environment, the online transaction workload is automatically redistributed without operator intervention.
Secondly, it is necessary to recover the elements of work that were in progress at the time of the failure.
Finally, when the failed element is repaired, it should be brought back into the configuration as quickly and transparently as possible to again start processing the workload. Parallel Sysplex technology enables all this to happen.

Generic resource management provides the ability to specify to VTAM® a common network interface. This can be used for CICS® terminal owning regions (TORs), IMS Transaction Manager, TSO, or DB2® distributed work. If one of the CICS TORs fails, for example, only a subset of the network is affected. The affected terminals are able to immediately log on again and continue processing after being connected to a different TOR.