Machines you can use for transfer : Grid front ends (lcgui.gridpp.rl.ac.uk)

Commands to be executed :

1. "GridEnv" (to get the Grid environment setup) followed by
2. "grid-proxy-init" to get a valid grid proxy. This proxy is typically valid for 12 hours to a day.
3. "myproxy-init -d" to get a valid MyProxy proxy. This proxy is by default valid for 168 hours (7 days). Remember the password you give for this MyProxy proxy.

Note that the step 3 above is required in case you plan to use the gLite tools to perform the file transfers. This is I think the recommended way anyway.

The commands available to use for the actual transfer of data :

• lcg-cp is one standard command which can be used with the -v (verbose) option if you want to. It needs a VO to be given (-vo lhcb) and then the source and destination urls. It accepts them both in the form of gsiftp turls and in the form of SRM surls. This command does not require a MyProxy proxy.
• Other commands in the lcg-** class exist, like lcg-rep. The full list can be obtained from the LCG users guide. Some of them will also update the file registry to let the others in LHCb know that the file copy is there to be used - if it is for public usage.
• glite-transfer-submit comes from the EGEE gLite project. It is more like a submission which then is taken up when there are enough resources. This requires a MyProxy proxy described above. It can take among others, the options -v (verbose) and -p **** (MyProxy proxy password)
• If you want to give multiple files to be transferred, you can use the "-f < file >" option. In this case, each line of the the file will have to contain exactly one source filename followed by one destination filename, with a space inbetween them. You can give upto 1000 filenames in a single job.
• More information can be obtained from "glite-transfer-submit -h" or from the glite users guide for file transfers
• Other commands in this series exist, like the glite-transfer-status, etc. They are listed in the gLite manual for remote file transfers.
• Apparently SRM surls are preferred for the following reasons :
• Performance : SRM surls are much faster when working with dCache or Castor2. They are just as faster otherwise
• Maintainance : Going through SRM enables the system manager to route the request through one of at least 4 servers, and distribute load better
• Information about using gridFTP within DIRAC (for LHCb only?) can be obtained from Andrew Smith's document at the following DIRAC wiki page.

For interactive copying of data to the storage systems from your home area at RAL, you can refer to the other web page on this website regarding Data Storage at RAL