Copying files between managed nodes using idlcalls

One of the most common requirements in a Tivoli site is to copy files from one managed node to another managed node. For example, we may need to synchronize various Tivoli configuration files and scripts across managed nodes/TMRs from time to time. There are few options to copy files remotely such as ftp, rcp, scp or data-moving services. While each has its own advantages, they suffer from some drawbacks in an enterprise-wide scenario.

Drawbacks of conventional file transfer tools
File transfer service is a platform independent service that can be used for copying files from one managed node to another managed node. But, it is not a secure way of transferring files as it may require password to be transmitted in a plain-text format. Moreover, copying files is not straight-forward with this method.

rcp command can be used for copying files remotely but it is not allowed in a secure environment. Moreover, rcp will work only across Unix managed nodes and it is very difficult to maintain/configure each manage node for rcp to work correctly.

scp command eliminates the security issue with the rcp command and it is platform-independent as well but still it is very difficult to setup each managed node for scp to work.

Data-moving service addresses most of the issues with these tools but it requires one of the managed nodes to be an endpoint. Moreover, it requires Software Distribution to be installed in the environment. This may not be a feasible option in all environments. Moreover, it is asynchronous in nature, so it may not be a good option for automated scripts that require the file copy to take place immediately.

gbscp.pl
To address these difficulties, we have come up with a perl4 based tool. It is a platform-independent utility that can be run on any managed node and it does not require any special setup. It uses Tivoli Management Framework to copy files and it is secure. This utility can be run from any managed node in the environment to copy files or directories and both the source as well as target could be two remote managed nodes.

Invoking gbscp.pl is easy. It accepts rcp-like command line, it requires two arguments viz. the source file/directory and the target directory. Please note that you can only specify the target directory but not target file name. The target file will have the same name as the source.

Here are some sample commands.

#Copies a file from local Windows managed node to a directory on a remote managed node
perl gbscp.pl C:/temp/test.txt tmr1:/apps/Tivoli/bin

# copies the bin directory and its subdirectories from remote managed node to local managed node
perl gbscp.pl tmr1:/apps/Tivoli/bin C:/apps/Tivoli

# copies a directory from a remote managed node to another remote managed node
perl gbscp.pl tmr1:/apps/Tivoli/bin tmr2:C:/apps/Tivoli

# copies a file from one directory to another locally. (why would I do that?)
perl gbscp.pl C:/temp/test.txt C:/apps/Tivoli

How does it work?
The gbscp.pl program needs just a running framework for data communication. It relies on a managed node idlcall to transfer files. The idlcall uses IOM channels to transfer data between managed nodes, so the data transfer is direct and it does not use the repeater hierarchy.

Limitations
The gbscp.pl should be good enough for basic file copying requirements. However, it has its own limitations. The gbscp.pl provides a simple copying feature and it does not have robust error checking capabilities at this time. The error code from the Tivoli idlcall is returned as the exit code. The exit code of zero signifies success and non-zero return code indicates failure.

Since the program uses IOM channels for data transfer, it may not be a good idea to transfer large files over a slow network as it would tie up oserv threads for an extended period of time.

The program uses colon (???????????????:')?as a delimiter for separating the hostname and the file name just like rcp/scp. Since colon is used in specifying the drive letter as well, this program assumes that the given string is a hostname if there are two more letters before the colon character. In other words, if the hostname contains single letter, this program may not work correctly.

Please note that the target directory must exist. The target directory is not created if it is missing.

On Unix/Linux systems, if the perl interpreter is located in any other directory other than /usr/bin, the first line in the program should be replaced with the actual path to the perl interpreter.

Download
Download gbscp.pl from here