When a server subsystem starts, identify some basic information for TCP/IP to the DFSMSrmm subsystem using the EDGRMMxx parmlib OPTION SERVER operand. See Defining system options: OPTION for information on the OPTION command. After the startup of the standard subsystem, DFSMSrmm communicates with TCP/IP and prepares to handle DFSMSrmm requests from client systems. The server verifies that TCP/IP and the specified PORT is available, determines its own default IP address and informs the operator that initialization is successful or issues error messages. As well as normal DFSMSrmm subsystem operation, such as processing of local requests, the server waits for and accepts connection requests, and processes requests from DFSMSrmm client systems. If the server task is unable to start successfully, you can still use DFSMSrmm as a standard subsystem until the server task problem is resolved.

When a client subsystem starts, identify some basic information for TCP/IP to the DFSMSrmm subsystem with the EDGRMMxx parmlib OPTION CLIENT operand. See Defining system options: OPTION for information on the OPTION command. During startup, the subsystem communicates with TCP/IP and prepares to send DFSMSrmm requests from the client to a server system. The client verifies that TCP/IP is available and that the server can be reached with the specified PORT, determines its own IP address, verifies the control data set ID matches that of the server, and informs the operator that initialization is successful or issues error messages. DFSMSrmm ignores any parmlib options not required for a client system. The client can connect to only one server system at a time. If the defined server is not available, the client issues a WTOR EDG0358D and waits for either the operator to reply with CANCEL, RETRY, or for the server to be available for connection.

DFSMSrmm issues a WTOR when a TCP/IP error occurs. RETRY processing relies on the operator replying to the WTOR. If the error is resolved and the operator has not replied to the WTOR, DFSMSrmm processing automatically continues and cancels the outstanding WTOR.

Once the client is started, no further verification of the server availability is performed unless a DFSMSrmm request is to be processed. When a request is processed and server communication fails or a time out occurs, and retry still cannot process the request, DFSMSrmm issues message EDG0358D to describe the error and prompts the operator to reply CANCEL or RETRY, and DFSMSrmm automatically continues if the error is resolved.

 F DFRMM,Q A 

The DFSMSrmm server processes local requests as if it runs as a standard system. In addition, client requests are accepted and processed synchronously while the requester on the client waits. There is no queue of client requests maintained on the server. The request queues maintained on the server are for local requests only. When you list the active tasks, using 'QUERY ACTIVE', the active local requests are listed together with the accepted client requests.

You must update your firewall to ensure that communication between DFSMSrmm clients and servers is allowed only for the defined IP addresses and ports. The DFSMSrmm subsystem does no authentication, encryption, or verification of connect requests received on the server other than to verify that it is a valid DFSMSrmm request and that control data set IDs match. You should also consider using RACF to protect the use of the IP addresses defined for DFSMSrmm and limit use of the IP address to the DFSMSrmm started task.

Tracing of the IP communication is enabled by the DFSMSrmm support. You will use TCP/IP facilities, such as TCP/IP component trace to gather information about the DFSMSrmm socket processing. See z/OS DFSMSrmm Managing and Using Removable Media for information on operator procedures.