General Considerations for Multi-Tasking Servers
- Initialization.
Regardless of the multi-tasking model you use, the server's main task should perform the initialization tasks, such as allocating common resources or issuing messages to operators.
- Security.
Consider the potential risks of running multiple users in the same address space.
- Workload balancing.
Consider using the allocate queue services described in Receiving Notification of Events to manage the installation's workload efficiently. To simplify workload balancing, have the same task perform the event notification functions for the server.
- Processing protected conversations.
Servers designed following the empowerment and unmanaged models may process protected conversations (conversations with a synchronization level of syncpt) as they would any other conversation, as long as each server subtask processes only one conversation at a time. Servers that are designed following the management-directed model, however, must register with registration services as a resource manager to process protected conversations using privately managed contexts.
If you want to code a management-directed model server to manage protected conversations, you need to understand the concepts and requirements for resource recovery in z/OS MVS Programming: Resource Recovery. Design this server and its subtasks to use allocate queue services, along with registration and context callable services, in the following sequence:
- Register for TP/LU pairs through the Register_For_Allocates service. The LUs for which the server registers must be defined as capable of handling conversations with a synchronization level of syncpt. See the session management section of z/OS MVS Planning: APPC/MVS Management for further information about enabling LUs for protected conversation support.
- Register with registration services through the Register_Resource_Manager service, supplying a resource manager name for this server. The service returns a resource manager token that the server uses on subsequent calls to registration and context services.
- Call the Set_Exit_Information service to cause the server resource manager state to change to SET state. The server is now in the correct state with context services to issue context callable services.
- Create a privately managed context through the Begin_Context service. The service returns a context token for the newly created context.
- Switch to the newly created context by issuing a call to the Switch_Context service. After the service returns, the privately managed context is the current context.
- Receive an inbound protected conversation by issuing the Receive_Allocate service. After the service returns, the identifier of this protected logical unit of work is associated with the privately managed context.
- Attach a subtask to process the protected conversation. The server must pass to the subtask not only the conversation ID, but also the context token for the privately managed context. Once the subtask receives control, it must issue the Switch_Context service, specifying that context token.
The server may then repeat steps 4 through 7 to receive additional allocate queue requests, each with a different context, for additional subtasks to process. For servers, only one protected conversation may be associated with a context at one time; so a server may issue another Receive_Allocate call before deallocating a previous allocate request only through the use of privately managed contexts.