A Routing Manager Model

This section presents a model of a routing manager which uses workload management services to accomplish the following objectives:

• Isolate different types of requests into separate server address spaces for integrity, security, and operational reasons.
• Have MVS™ adjust the number of server address spaces to meet the goals of the workload.
• Have MVS balance the workload across a sysplex by selecting the best system on which to start a server.
• Associate work coming into the server with a service class goal.
• Report goals versus actuals.
• Report response time information.

Figure 19 shows the suggested services for a routing manager for managing server address spaces and balancing workload.

Figure 19. Example of routing manager services

Figure 19 shows a routing manager connecting to workload management and establishing itself as a routing manager. It then issues a “find server” for each client request for server location. Workload management is then able to create server address spaces as needed and keep track of the servers across the sysplex. When the client contacts the server, the server creates an enclave on behalf of the client so the work request can be managed to the customer goals.

The detailed sequence of events in Figure 19 is:

1. Establish routing manager

   The routing manager address space starts up through either a manual start or customer automation. During its initialization, it issues the IWM4CON service with the ROUTER=YES parameter to indicate the intent to use routing manager services. The routing manager supplies the subsystem type (SUBSYS parameter) and subsystem name (SUBSYSNM parameter). These parameters identify the type of work associated with the routing manager.

2. Request server routing information

   Once initialized in step 1, the routing manager is ready to receive requests to locate servers. In response to such a request, the routing manager calls the IWMSRFSV service, passing the desired application environment name (via the APPLENV= parameter). The output returned will be the routing information needed for the client to contact the selected server directly. (The specific content of this information is defined by the client and passed by the server via the SERVER_DATA= parameter, as described in step 3.)

   If no eligible servers exist, workload management will proceed to step 3 to start a server.

3. Establish server

   If this step is necessary, the client program will be suspended until the new server address space is created (possibly on another MVS image). For an application environment defined for a routing server, workload management starts at most one server address space per system instance in the sysplex. The first server is started on the system with the most available capacity at the lowest importance level. Subsequent servers are started on other systems in the sysplex when the work running in the existing servers is not meeting its goals. However, if the workload diminishes for a routing manager, workload management does not decrease the number of servers in the sysplex. The number of servers remains at the high water mark.

   It is possible to run more than one instance of a subsystem in the sysplex, meaning they have the same subsystem type, and therefore the same application environments, but different subsystem names as specified on IWM4CON. The above rules for starting servers apply separately to each subsystem instance. In other words, for each instance, you can have up to one server per system per application environment.

   During server initialization, the server invokes the IWM4CON service with the SERVER_MANAGER=YES and SERVER_TYPE=ROUTER parameters, and information in the SERVER_DATA= parameter to uniquely identify the server. The subsystem type and name specified must match that of the associated routing manager instances which will route clients to the server (as defined in step 1). The WORK_MANAGER= parameter must remain the default YES so that the server can create independent enclaves in the next step. In addition, the address of an exit routine must be identified on the SRV_MGR_EXIT= parameter. Refer to Using the Routing Server Connect Exit. Workload management invokes this exit to initiate the shutdown of the server address space. The exit is expected to initiate the shutdown of the server address space. Input to the exit is mapped by the list form of the IWMSCXIT macro instruction. For more information on the quiesce process for an application environment, see step 6 below, as well as the “Defining Application Environments” chapter in z/OS MVS Planning: Workload Management.

4. Create enclave

   The server address space receives a work request directly from the client and uses the IWM4ECRE service to create an enclave (normally one per request, depending on the definition of the request).

   For the duration of the processing of a request, the client task is joined to the enclave via the IWMEJOIN service so that it can be managed to the installation performance objectives. While the task is part of the enclave, it should only be doing work on behalf of the enclave. Upon completion of the request, the task leaves the enclave via the IWMELEAV service.

   Note:

   While IWM4STBG and IWM4STEN are similar in many ways to IWMEJOIN and IWMELEAV, they cannot be used here, as queueing services are not involved.
5. Delete enclave

   When work is completed, the server address space informs workload management via the IWM4EDEL service.

6. Terminate server address space

   Under normal circumstances, it is expected that a server address space terminates only when directed to do so by workload management through the connect exit. Possible reasons for the exit being invoked could be:

   • Operator entered a VARY WLM,QUIESCE or VARY WLM,REFRESH command
   • Policy activated from new service definition which no longer includes the application environment associated with the server.
   • WLM determines that the server is not needed to meet the goals of the enclave's service class.

   The server is expected to complete any active work requests, clean up, and then disconnect and terminate from workload management through the IWM4DIS service.

   If the server encounters a failure that forces it to terminate, it should disconnect from workload management as part of its shutdown. If the server address space terminates without explicitly disconnecting from workload management, workload management detects the termination and performs the IWM4DIS processing at that time.

7. Terminate routing manager address space

   When the routing manager terminates normally, it is expected to quiesce its activities and disconnect from workload management using the IWM4DIS service. If the routing manager address space terminates without first disconnecting from workload management, workload management detects the termination and performs the IWM4DIS processing at that time. The disconnect and termination of a routing manager does not cause the related server address spaces to terminate. It is the responsibility of the subsystem to coordinate termination processing between the routing manager address space and the servers.