Task and workload management in a concurrent server program

When a program is started by MVS™, it runs as the main task of the address space in which it was started. In the examples in this topic, the main task is used as the main process of our concurrent server implementation. The child processes are then started as subtasks to the main.

Generally, there are two ways to manage your processes:

Each time a connection request arrives, a new subtask is started. The subtask makes one connection and then terminates.
During initialization, the main task starts a number of subtasks. Each subtask initializes and enters wait-for-work status. When a connection request arrives, the main process selects the first subtask waiting for work and schedules the connection to that subtask. The subtask processes the connection and, when complete, reenters wait-for-work status.

The second process is most efficient because it limits the overhead of creating new tasks to one time during server startup. But, it is also more complicated to implement than the other process because:

You must decide on the number of server subtasks to be started during initialization. If more connection requests arrive than you have server subtasks available, you must include code to deal with that situation. (Reject the connection or dynamically change the number of subtasks in your concurrent server address space. This is called workload management.)
The subtasks must be reusable and include logic to enter wait-for-work status; they must be able to process connection requests serially.
The main process must be able to manage situations in which a server subtask abends or terminates.
To achieve a graceful shutdown, you must implement a technique to terminate subtasks in an orderly manner. A simple technique is to post the subtask from the main process with a return code. For example, use a return code of 0 for work and some other value for termination.

In the concurrent MVS server example (Figure 1), the technique using a pool of subtasks that waited for work was presented. We did not implement a dynamic increase of subtasks, but sent a negative reply back to the requester when no server subtasks were available.