Overview

Transfer operations take place within the context of a transfer session. A transfer operation is initiated once the Universal Data Mover Manager has established a transfer session with the primary and secondary transfer servers. All subsequent transfer operations take place between the primary and secondary transfer servers.

Universal Data Mover transfer sessions can be either two-party or three-party.

Note

For information on transfer operations specific to z/OS and IBM i operating systems, see:

Logical Names

When a transfer session is established, the user gives each server a unique logical name. Commands addressed to a particular server reference this logical name.

Two-Party Transfer Sessions

For a two-party transfer session, the Universal Data Mover Manager also acts as the primary transfer server, running in the directory – and under the user ID – under which the Manager was launched. This means that the machine on which Manager resides is the first endpoint of the transfer.

With a two-party transfer session, the secondary server is invoked by the manager / primary server via the Universal Broker. The second endpoint of the transfer session will be on the machine in which the secondary server was spawned. Transfer operations occur between the manager / primary server and the secondary server.

(See the following illustration.)

Three-Party Transfer Sessions

For a three-party transfer session, the Universal Data Mover Manager acts solely as a control point for transfer operations, sending commands to the primary and secondary servers to be executed. Both the primary and secondary servers are spawned via the Universal Broker, and transfer operations take place between the two machines under which these servers are running.

(See the following illustration.)

Transfer Sessions (Illustrated)

Opening a Two-Party Transfer Session

All sessions are established using the open command. At its simplest, the open command specifies the primary and secondary servers for the session:

In this example, logical1 and logical2 are the user-assigned logical names of the primary and secondary servers, respectively. Each of these parameters is set to the host name or IP address of the corresponding server.

For two-party transfer sessions, where the UDM Manager acts as the primary server, hostname is not the host address of the local machine (this would initiate a three-party transfer with the primary server running on the local machine). Instead, the host address is either the name local or the asterisk ( * ) character:

In this example, a two-party transfer session is established between the UDM Manager, acting as the primary server with the logical name machine1, and another machine with the host name somentmachine, with the logical name machine2.

An alternate method of establishing a two-party transfer is simply to give the secondary server as a parameter to the open command:

In this example, a two-party transfer session is implied. In such cases, the logical name of the UDM Manager / primary server side of the transfer session always will be local.

Opening a Three-Party Transfer Session

A three-party transfer session can be opened using the same syntax as a two-party transfer session. However, both the primary and secondary servers must be specified explicitly, and the host name of the primary server must be a valid IP or host address:

In this example, a three-party transfer session is established between a machine with the host name somemvsmachine, given the logical name machine1, and a machine with the host name somentmachine, given the logical name machine2.

A Stonebranch Tip

It is important to keep in mind that the host name of the secondary transfer server should be specified from the point of view of the primary server, since it will be making the connection to the secondary server.

Depending on your network configuration, the host name for the secondary server might be different from the UDM Manager's perspective than that of the primary server's.

Session Options

The examples given thus far show the simplest versions of the open command. Additional options can follow each server name, such as the port on which the Universal Broker is listening, the codepage that the server uses for text translation, authentication information, and references for a file from which these options are read (this file may be encrypted, if desired). At the end of the open command are optional parameters that specify the type of encryption and compression used for the data transfer operations.

(See Universal Data Mover Commands for detailed information on these parameters).

A Stonebranch Tip

Unless otherwise specified, UDM transfers file data using the SSL/TLS protocol and the NULL-MD5 cipher suite.

If you do not want to take the performance hit of SSL/TLS, and authentication of the transferred data is not required, you may want encrypt=NULL-NULL specified as a session option.

However, the NULL-NULL cipher suite must be in the cipher list for all UDM servers involved in the transfer.

Closing a Session

When all transfer operations have concluded, you can close a transfer session by issuing a close command. At this point, UDM is ready to initiate another transfer session.

Alternatively, if you want to exit UDM, you can issue a quit command, which closes the transfer session and exits the UDM Manager.

Additional Information

The following pages provide additional detailed information for Universal Data Mover Transfer Operations: