ValuesMeaning
N.A./NA Not Available - the function is not available in the SRM and availability is known in advance.
N.T. Not Tried - previous dependent operation failed and following operation was not tried.
N.S. Not Supported - SRM returned that the function is not supported.
Failed The requested operation is failed.
Exception The operation resulted in the exception. It needs a closer look at the problems.
TimedOut The requested operation is timed out. The SRM server may have a long queue and it takes too long for a tester to wait for the results. Default waiting time is 5 minutes.
Ok The operation was successfully completed.


ColorMeaning
Red one or more functions throws an exception, failed or not-tried due to the previous failures.
Orange one or more functions timed out. could not determine if the function was successful or failed. space related functions not successful (because many dCache servers do not support dynamic space reservation by default).
Yellow some functions timed out.
Olive Yellow remote copy functions not successful. usually it's not a fault at the testing site, but at the remote site.
Green/Lime all functions are successful.
White undetermined.


OperationsDescription
Discovery Operations
  • ping
  • discover transfer protocol information
Data Transfer Operations
  • PUT: writing a file into the SRM. srmPrepareToPut, srmStatusOfPutRequest, gsiftp file transfer, and srmPutDone are tested.
  • GET: reading a file from the SRM. srmPrepareToGet, srmStatusOfGetRequest, gsiftp file transfer and srmReleaseFIles are tested.
  • BringOnline: bring files online upon the clients request so that client can make certain data readily available for future access. In hierarchical storage systems, it is expected to stage files to the top hierarchy and make sure that the files stay online for a certain period of time. srmBringOnling, srmStatusOfBringOnline and srmReleaseFiles are tested.
  • GridFTP-Get: reading a file from the gridftp server, resulted from the GET operation. Transfer URL is returned from the SRM.
  • GridFTP-Put: writing a file into the gridftp server, resulted from the PUT operation. Transfer URL is returned from the SRM.
Directory Operations
  • Listing: browsing an url and get information about the url. srmLs is tested.
  • Move: moving an url to another url. srmMv is tested.
  • Remove: removing an surl. srmRm is tested.
  • Mkdir: creating a directory. srmMkdir is tested.
  • Rmdir: removing a directory. srmRmdir is tested.
Space Management Operations
  • Reserve: reserving a space in advance for the upcoming requests to get some guarantee on the file management. srmReserveSpace and srmStatusOfReserveSpace are tested.
  • Release: releasing an occupied space. srmReleaseSpace is tested.
  • GetSpaceInfo: getting information of a space. srmGetSpaceMetaData is tested.
  • GetSpaceTokens: getting space tokens for currently allocated spaces for the client. srmGetSpaceTokens is tested.
Data Transfer Copy Operations from GSIFTP source
  • request to copy files from a remote gsiftp storage sites into the targetted SRM storage sites. srmCopy and srmStatusOfCopyRequest are tested.
Data Transfer Copy/Pull Operations
  • request to copy files from source SRM storage sites into the target SRM storage sites by PULL mode. The srmCopy request goes to the target SRM, and the target SRM "pulls" a file from the source SRM. srmCopy and srmStatusOfCopyRequest are tested.
  • CASTOR: As CASTOR being the target SRM, srmCopy request goes to the CASTOR to pull a file from the source SRMs.
  • DPM: As DPM being the target SRM, srmCopy request goes to the DPM to pull a file from the source SRMs.
  • dCache: As dCache being the target SRM, srmCopy request goes to the dCache to pull a file from the source SRMs.
  • BeStMan: As BeStMan being the target SRM, srmCopy request goes to the BeStMan to pull a file from the source SRMs.
  • StoRM: As StoRM being the target SRM, srmCopy request goes to the StoRM to pull a file from the source SRMs.
Data Transfer Copy/Push Operations
  • request to copy files from source SRM storage sites into the target SRM storage sites by PUSH mode. The srmCopy request goes to the source SRM, and the source SRM "pushs" a file from the source SRM to its target SRM.
  • CASTOR: As CASTOR being the source SRM, srmCopy request goes to the CASTOR to push a file from CASTOR to the target SRMs.
  • DPM: As DPM being the source SRM, srmCopy request goes to the DPM to push a file from DPM to the target SRMs.
  • dCache: As dCache being the source SRM, srmCopy request goes to the dCache to push a file from dCache to the target SRMs.
  • BeStMan: As BeStMan being the source SRM, srmCopy request goes to the BeStMan to push a file from BeStMan to the target SRMs.
  • StoRM: As StoRM being the source SRM, srmCopy request goes to the StoRM to push a file from StoRM to the target SRMs.