Workload balancing in a sysplex

Workload balancing is implemented at two levels:

  1. To balance client connections across the listener regions, you can use any of the following methods:
    • Connection optimization by means of dynamic Domain Name System (DNS) registration.
    • IP routing.
    • A combination of connection optimization and IP routing.

    With connection optimization by means of dynamic DNS registration, for example, multiple CICS regions are started to listen for IIOP requests on the same port (using virtual IP addresses). Each client IIOP connection request contains a generic host name and port number. The generic host name in each connection request is resolved to a real IP address by MVS™ DNS and Workload Management (WLM) services.

  2. To balance OTS transactions across the AORs, you can use either of the following:
    • CICSPlex SM
    • A customized version of the CICS distributed routing program, DFHDSRP.
    Important:
    1. It is convenient to talk of balancing (or dynamically routing) OTS transactions across AORs. Strictly speaking, however, what are dynamically routed are method requests for enterprise beans and CORBA stateless objects. There is a correlation between routing method requests dynamically and routing OTS transactions dynamically: CICS invokes the routing program for requests for methods that will run under a new OTS transaction, but not for requests for methods that will run under an existing OTS transaction—these it directs automatically to the AOR in which the existing OTS transaction runs. However, because requests for methods that will run under no OTS transaction can also be dynamically routed, the correlation is not exact.
    2. We must be clear about what we mean by “new” and “existing” OTS transactions. For the purposes of this section:
      1. By a “new” OTS transaction we mean an OTS transaction in which the target logical server is not already participating, prior to the current method call; not necessarily an OTS transaction that was started immediately before the method call.
      2. By an “existing” OTS transaction we mean an OTS transaction in which the target logical server is already participating, prior to the current method call; not simply an OTS transaction that was started some time ago.
    3. For example, if a client starts an OTS transaction, does some work, and then calls a method on an enterprise bean with the Supports transaction attribute, so far as the CICS EJB server is concerned this is a “new” OTS transaction, because the server has not been called within this transaction's scope before. If the client then makes a second and third method call to the same target object, before committing its OTS transaction, these second and third calls occur within the scope of the existing OTS transaction.