IWM4SRSC – Obtain Server-Specific Routing Information

The IWM4SRSC service provides information about how well a server is suitable to receive work from a WLM point-of-view. The IWM4SRSC service allows to check a specific server before routing work to it from WLM. Thus, the information obtained can be used for making balanced routing decisions.

The input to the IWM4SRSC service is the STOKEN of an address space. The output is an indicator, of how well the address space itself, the transactions or enclaves – if it is a registered transaction server, an enclave server or an enclave owner – are performing relative to their WLM goal and to the displaceable capacity for its WLM importance on that system.

The service returns an indicator that can be used for load balancing by comparing it to calls of this service for other servers.

The indicator output is a weight. WLM provides two methods for computing the weight, which can be selected with the optional input parameter METHOD. The default method is PROPORTIONAL, the other one is EQUICPU.

With PROPORTIONAL, the weight is calculated based on six factors: it is a combination of the three processor weights (CPU weight, ZAAP weight and ZIIP weight) and their respective consumed service units repartition. With EQUICPU, WLM computes the weight by trying to simulate a 100% usage of the system capacity, and determining the capacity of a CPU-only system having equivalent resource consumption.

The CPU, ZAAP and ZIIP weights are each computed based on the following four factors:

• The first factor is how well this server, or the transactions or enclaves it is related to, fulfill their goals.
• The second factor is the abnormal termination factor. This depends on the ratio of abnormal terminations to normal terminations as reported by the IWMRPT service. If no terminations were reported by IWM4RPT, this factor is neutral (=1).
• The third factor is the health factor of this server. It is dependent on the health indicator which was reported to WLM for this server by the IWM4HLTH service or by IWMSRSRG. If no health indicator was reported, this factor is also neutral.
• The fourth factor is how much other work with lower importance can be displaced, if it receives more work to handle on this system. With the optional IL_WEIGHTING parameter, the caller can set the relative balance between the lower and the higher importance levels.

These four factors are combined to create the output processor WEIGHT as a number.

To make it easier for the caller to determine, how far the weights were influenced by the abnormal terminations and health factors, those values can also be output through the optional parameters ABNORM_COUNT and HEALTH.

The processor weights are returned through the optional CPUWEIGHT, ZAAPWEIGHT and ZIIPWEIGHT parameters. The respective parts of these weights in the WEIGHT are returned through the optional parameters CPUPROPORTION, ZAAPPROPORTION, and ZIIPPROPORTION.

If there are pre-V1R9 systems in the sysplex, the zAAP and zIIP weights and proportions are automatically set to 0, because pre-V1R9 systems do not have such weights and could not be compared to V1R9 systems. For the same reason, if there are pre-V1R11 systems in the sysplex, only METHOD=PROPORTIONAL will be used, even if METHOD=EQUICPU is specified.

The WEIGHT is equal to the sum of these three proportion fields. As WLM computes the values with higher precision, and rounds them before output, the WEIGHT actually returned is probably greater than the sum of the returned proportion fields by one or two units.

A scenario where TCP/IP communicates on each system with WLM to obtain information about the servers which receive work is described in the following.

TCP/IP recognizes the server address spaces when they open a port. It invokes the IWM4SRSC service to WLM with an identification of the address space (STOKEN). WLM then finds out whether that address space is a registered WLM server address space or whether it creates WLM transactions which can execute in other server address spaces. The following possibilities are considered:

• The address space does not create any enclaves and is not a server address space registered to WLM. The FTP daemon is such an address space, for example. In this case WLM uses the service class the address space has been classified to.
• The address space is not a registered server address space but it creates independent enclaves which are processed by other address spaces on that system. In this case WLM has to use the service classes for the enclaves which are owned by this address space.
  Note:

  There can be multiple service classes which are associated with enclaves. In this case the service class with the highest transaction rate is used.
• The address space is a server address space from the point-of-view of WLM. In this case it is either an enclave or a transaction server, for example, CICS® or IMS™. In this case WLM uses the service classes the enclaves or CICS or IMS transactions are classified to.