The Storage Resource Manager

Interface Specification

 

Version 2.2

 

 

2 April 2007

 

 

Collaboration Web:

http://sdm.lbl.gov/srm-wg

Document Location:

http://sdm.lbl.gov/srm-wg/doc/SRM.v2.2.html

 

 

 

Editors:

Alex Sim

Lawrence Berkeley National Laboratory

Arie Shoshani

Lawrence Berkeley National Laboratory

 

 

 

Contributors:

Timur Perelmutov

Don Petravick

Fermi National Accelerator Laboratory (FNAL), USA

Ezio Corso

Luca Magnoni

International Centre for Theoretical Physics (ICTO), Italy

Istituto Nazionale di Fisica Nucleare (INFN), Italy

Junmin Gu

Lawrence Berkeley National Laboratory (LBNL), USA

Paolo Badino

Olof Barring

Jean-Philippe Baud

Flavia Donno

Maarten Litmaath

LHC Computing Project (LCG, CERN), Switzerland

Shaun De Witt

Jens Jensen

Rutherford Appleton Laboratory (RAL), England

Michael Haddox-Schatz

Bryan Hess

Andy Kowalski
Chip Watson

Thomas Jefferson National Accelerator Facility (TJNAF), USA

 

 


Copyright Notice

 

© Copyright Lawrence Berkeley National Laboratory (LBNL), Fermi National Accelerator Laboratory (FNAL), Jefferson National Accelerator Facility (JLAB), Rutherford Appleton Laboratory (RAL), Istituto Nazionale di Fisica Nucleare (INFN), International Centre for Theoretical Physics (ICTO), and European Organization for Nuclear Research (CERN) 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007. All Rights Reserved.

 

Permission to copy and display this “The Storage Resource Manager Interface Specification” (“this paper"), in any medium without fee or royalty is hereby granted, provided that you include the following on ALL copies of this paper, or portions thereof that

you make:

1. A link or URL to this paper at this location.

2. This Copyright Notice as shown in this paper.

 

THIS PAPER IS PROVIDED "AS IS," AND Lawrence Berkeley National Laboratory, Fermi National Accelerator Laboratory, Jefferson National Accelerator Facility, Rutherford Appleton Laboratory and European Organization for Nuclear Research (COLLECTIVELY, THE “COLLABORATION”) MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF  MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT OR TITLE; THAT THE CONTENTS OF THIS PAPER ARE SUITABLE FOR ANY PURPOSE; NOR THAT THE IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS.

 

THE COLLABORATION WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF OR RELATING TO ANY USE OR DISTRIBUTION OF THIS PAPER.

 

The names and trademarks of the Collaboration may NOT be used in any manner, including advertising or publicity pertaining to this paper or its contents, without specific, written prior permission. Title to copyright in this paper will at all times remain with the Collaboration.

 

No other rights are granted by implication, estoppel or otherwise.

 

PORTIONS OF THIS PAPER WERE PREPARED AS AN ACCOUNT OF WORK FUNDED BY U.S. Department of Energy AT UNIVERSITY OF CALIFORNIA'S LAWRENCE BERKELEY NATIONAL LABORATORY. NEITHER THE AUTHORS, NOR THE UNITED STATES GOVERNMENT OR ANY AGENCY THEREOF, NOR THE UNIVERSITY OF CALIFORNIA, NOR ANY OF THEIR EMPLOYEES OR OFFICERS, NOR ANY OTHER COPYRIGHT HOLDERS OR CONTRIBUTORS, MAKES ANY WARRANTY, EXPRESS OR IMPLIED, OR ASSUMES ANY LEGAL LIABILITY OR RESPONSIBILITY FOR THE ACCURACY, COMPLETENESS, OR USEFULNESS OF ANY INFORMATION, APPARATUS, PRODUCT, OR PROCESS DISCLOSED, OR REPRESENTS THAT ITS USE WOULD NOT INFRINGE PRIVATELY OWNED RIGHTS. REFERENCE HEREIN TO ANY SPECIFIC COMMERCIAL PRODUCT, PROCESS, OR SERVICE BY TRADE NAME, TRADEMARK, MANUFACTURER, OR OTHERWISE, DOES NOT NECESSARILY CONSTITUTE OR IMPLY ITS ENDORSEMENT, RECOMMENDATION, THE UNITED STATES GOVERNMENT OR ANY AGENCY THEREOF OR ANY OTHER COPYRIGHT HOLDERS OR CONTRIBUTORS. THE VIEW AND OPINIONS OF AUTHORS EXPRESSED HEREIN DO NOT NECESSARILY STATE OR REFLECT THOSE OF THE UNITED STATES GOVERNMENT OR ANY AGENCY THEREOF, OR THE ENTITY BY WHICH AN AUTHOR MAY BE EMPLOYED.

 

This paper preparation has been partially supported by the Office of Energy Research, Office of Computational and Technology Research, Division of Mathematical, Information, and Computational Sciences, of the U.S. Department of Energy under Contract No. DE-AC03-76SF00098.

The U.S. Government retains for itself, and others acting on its behalf, a paid-up, nonexclusive, irrevocable worldwide license in said article to reproduce, prepare derivative works, distribute copies to the public, and perform publicly and display publicly, by or on behalf of the Government.


Table of Contents

 

Introduction. 5

Meaning of terms. 5

1. Common Type Definitions. 7

1.1. File Storage Type. 7

1.2. File Type. 7

1.3. Retention Policy. 7

1.4. Access Latency. 7

1.5. Permission Mode. 8

1.6. Permission Type. 8

1.7. Request Type. 8

1.8. Overwrite Mode. 8

1.9. File Locality. 8

1.10. Access Pattern. 9

1.11. Connection Type. 9

1.12. Status Codes. 9

1.13. Retention Policy Info. 10

1.14. Request Token. 10

1.15. User Permission. 10

1.16. Group Permission. 11

1.17. Size in Bytes. 11

1.18. UTC Time. 11

1.19. Time in Seconds (Lifetime and RequestTime) 11

1.20. SURL. 11

1.21. TURL. 12

1.22. Return Status. 12

1.23. Return Status for SURL. 12

1.24. File MetaData. 12

1.25. Space MetaData. 13

1.26. Directory Option. 13

1.27. Extra Info. 13

1.28. Transfer Parameters. 14

1.29. File Request for srmPrepareToGet. 14

1.30. File Request for srmPrepareToPut. 14

1.31. File Request for srmCopy. 14

1.32. Return File Status for srmPrepareToGet. 14

1.33. Return File Status for srmBringOnline. 15

1.34. Return File Status for srmPrepareToPut. 15

1.35. Return File Status for srmCopy. 15

1.36. Request Summary. 16

1.37. Return Status for SURL. 16

1.38. Return File Permissions. 16

1.39. Return Permissions on SURL. 16

1.40. Return Request Tokens. 17

1.41. Supported File Transfer Protocol 17

2. Space Management Functions. 18

2.1. srmReserveSpace. 18

2.2. srmStatusOfReserveSpaceRequest. 20

2.3. srmReleaseSpace. 21

2.4. srmUpdateSpace. 23

2.5. srmStatusOfUpdateSpaceRequest. 24

2.6. srmGetSpaceMetaData. 25

2.7. srmChangeSpaceForFiles. 27

2.8. srmStatusOfChangeSpaceForFilesRequest. 29

2.9. srmExtendFileLifeTimeInSpace. 31

2.10. srmPurgeFromSpace. 33

2.11. srmGetSpaceTokens. 34

3. Permission Functions. 36

3.1. srmSetPermission. 36

3.2. srmCheckPermission. 37

3.3. srmGetPermission. 38

4. Directory Functions. 40

4.1. srmMkdir. 40

4.2. srmRmdir. 41

4.3. srmRm... 41

4.4. srmLs. 43

4.5. srmStatusOfLsRequest. 45

4.6. srmMv. 47

5. Data Transfer Functions. 49

5.1. srmPrepareToGet. 49

5.2. srmStatusOfGetRequest. 52

5.3. srmBringOnline. 55

5.4. srmStatusOfBringOnlineRequest. 59

5.5. srmPrepareToPut. 62

5.6. srmStatusOfPutRequest. 66

5.7. srmCopy. 69

5.8. srmStatusOfCopyRequest. 73

5.9. srmReleaseFiles. 76

5.10. srmPutDone. 78

5.11. srmAbortRequest. 79

5.12. srmAbortFiles. 80

5.13. srmSuspendRequest. 82

5.14. srmResumeRequest. 82

5.15. srmGetRequestSummary. 83

5.16. srmExtendFileLifeTime. 84

5.17. srmGetRequestTokens. 86

6. Discovery Functions. 88

6.1. srmGetTransferProtocols. 88

6.2. srmPing. 88

7. Appendix. 90

7.1. Status Code Specification. 90

7.2. SRM WSDL discovery method. 91

7.3. Changes log. 94

 


 

Introduction

 

This document contains the interface specification of SRM 2.2.  It incorporates the functionality of SRM 2.0 and SRM 2.1, but is much expanded to include additional functionality, especially in the area of dynamic storage space reservation and directory functionality in client-acquired storage spaces.

 

This document reflects the discussions and conclusions of a 2-day meeting in May 2006, as well as email correspondence and conference calls.  The purpose of this activity is to further define the functionality and standardize the interface of Storage Resource Managers (SRMs) – a Grid middleware component. 

 

The document is organized in four sections.  The first, called “Defined Structures” contain all the type definitions used to define the functions (or methods).  The next 5 sections contain the specification of “Space Management Functions”, “Permission Functions”, “Directory Functions”, “Data Transfer Functions” and “Discovery Functions”.  All the “Discovery Functions” are newly added functions.

 

It is advisable to read the document SRM.v2.2.changes.doc posted at http://sdm.lbl.gov/srm-wg before reading this specification.

 

Meaning of terms

By “https” we mean http protocol with GSI authentication. It may be represented as “httpg”. At this time, any implementation of http with GSI authentication could be used. It is advisable that the implementation is compatible with Globus Toolkit 3.2 or later versions.

 

 

·         The definition of the type “anyURI” used below is compliant with the XML standard. See http://www.w3.org/TR/xmlschema-2/#anyURI.   It is defined as: "The lexical space of anyURI is finite-length character sequences which, when the algorithm defined in Section 5.4 of [XML Linking Language] is applied to them, result in strings which are legal URIs according to [RFC 2396], as amended by [RFC 2732]".

 

·         In “localSURL”, we mean local to the SRM that is processing the request.

 

·         authorizationID : from the SASL RFC 2222
During the authentication protocol exchange, the mechanism performs authentication, transmits an authorization identity (frequently known as a userid) from the client to server…. The transmitted authorization identity may be different than the identity in the client’s authentication credentials. This permits agents such as proxy servers to authenticate using their own credentials, yet request the access privileges of the identity for which they are proxying. With any mechanism, transmitting an authorization identity of the empty string directs the server to derive an authorization identity from the client’s authentication credentials.

 

·         Regarding file sharing by the SRM, it is a local implementation decision.  An SRM can choose to share files by proving multiple users access to the same physical file, or by copying a file into another user’s space.  Either way, if an SRM chooses to share a file (that is, to avoid reading a file over again from the source site) the SRM should check with the source site whether the user has a read/write permission. Only if permission is granted, the file can be shared.

 

·         The word “pinning” is limited to the “copies” or “states” of SURLs and the Transfer URLs (TURLs).

 

·         For each function, status codes are defined with basic meanings for the function. Only those status codes are valid for the function. Specific cases are not stated for each status code. If other status codes need to be defined for a specific function, send an email to the collaboration to discuss the usage.

 


1. Common Type Definitions

 

Namespace SRM

 

Notation: underlined attributes are REQUIRED

 

1.1. File Storage Type

enum                    TFileStorageType            {VOLATILE, DURABLE, PERMANENT}

 

o   Volatile file has an expiration time and the storage may delete all traces of the file when it expires.

o   Permanent file has no expiration time.

o   Durable file has an expiration time, but the storage may not delete the file, and should raise error condition instead.

 

1.2. File Type

enum                    TFileType                            {FILE, DIRECTORY, LINK}

 

1.3. Retention Policy

enum                    TRetentionPolicy             { REPLICA , OUTPUT ,  CUSTODIAL }

 

o   Quality of Retention (Storage Class) is a kind of Quality of Service. It refers to the probability that the storage system lose a file. Numeric probabilities are self-assigned.

·         Replica quality has the highest probability of loss, but is appropriate for data that can be replaced because other copies can be accessed in a timely fashion.

·         Output quality is an intermediate level and refers to the data which can be replaced by lengthy or effort-full processes.

·         Custodial quality provides low probability of loss.

o   The type will be used to describe retention policy assigned to the files in the storage system, at the moments when the files are written into the desired destination in the storage system. It will be used as a property of space allocated through the space reservation function. Once the retention policy is assigned to a space, the files put in the reserved space will automatically be assigned the retention policy of the space. The assigned retention policy on the file can be found thought the TMetaDataPathDetail structure returned by the srmLs function.

 

1.4. Access Latency

enum                    TAccessLatency   { ONLINE,  NEARLINE }

 

o   Files may be Online, Nearline or Offline. These terms are used to describe how latency to access a file is improvable. Latency is improved by storage systems replicating a file such that its access latency is online.

·         The ONLINE cache of a storage system is the part of the storage system which provides file with online latencies.

·         ONLINE has the lowest latency possible. No further latency improvements are applied to online files.

·         NEARLINE file can have their latency improved to online latency automatically by staging the file to online cache.

·         For completeness, we also describe OFFLINE here.

·         OFFLINE files need a human to be involved to achieve online latency.

·         For the SRM we only keep ONLINE and NEARLINE.

o   The type will be used to describe a space property that access latency can be requested at the time of space reservation. The content of the space, files may have the same or “lesser” access latency as the space.

 

1.5. Permission Mode

enum                    TPermissionMode          {NONE, X, W, WX, R, RX, RW, RWX}

 

1.6. Permission Type

enum                    TPermissionType             {ADD, REMOVE, CHANGE}

 

1.7. Request Type

enum                    TRequestType   { PREPARE_TO_GET,

                                                                PREPARE_TO_PUT,

                                                                COPY,

                                                                BRING_ONLINE,

                                                                RESERVE_SPACE,

                                                                UPDATE_SPACE,

                                                                CHANGE_SPACE_FOR_FILES,

LS }

 

1.8. Overwrite Mode

enum                    TOverwriteMode            {NEVER,

ALWAYS,

WHEN_FILES_ARE_DIFFERENT}

 

o   Use case for WHEN_FILES_ARE_DIFFERENT can be that files are different when the declared size for an SURL is different from the actual one, or that the checksum of an SURL is different from the actual one.

o   Overwrite mode on a file is considered higher priority than pinning a file. Where applicable, it allows to mark a valid Transfer URL to become invalid when the owner of the SURL issues an overwrite request.

 

1.9. File Locality

enum                    TFileLocality      { ONLINE, 

                                NEARLINE,

ONLINE_AND_NEARLINE,

LOST,

NONE.

UNAVAILABLE }

 

o   Files may be located online, nearline or both. This indicates if the file is online or not, or if the file reached to nearline or not. It also indicates if there are online and nearline copies of the file.

·         The ONLINE indicates that there is a file on online cache of a storage system which is the part of the storage system, and the file may be accessed with online latencies.

·         The NEARLINE indicates that the file is located on nearline storage system, and the file may be accessed with nearline latencies.

·         The ONLINE_AND_NEARLINE indicates that the file is located on online cache of a storage system as well as on nearline storage system.

·         The LOST indicates when the file is lost because of the permanent hardware failure.

·         The NONE value shall be used if the file is empty (zero size). 

·         The UNAVAILABLE indicates that the file is unavailable due to the temporary hardware failure.

o   The type will be used to describe a file property that indicates the current location or status in the storage system.

 

1.10. Access Pattern

enum                     TAccessPattern   { TRANSFER_MODE,  PROCESSING_MODE }

 

o   TAccessPattern will be passed as an input parameter to the srmPrepareToGet and srmBringOnline functions. It will make a hint from the client to SRM how the Transfer URL (TURL) produced by SRM is going to be used. If the parameter value is “ProcessingMode”, the system may expect that client application will perform some processing of the partially read data, followed by more partial reads and a frequent use of the protocol specific “seek” operation. This will allow optimizations by allocating files on disks with small buffer sizes. If the value is “TransferMode” the file will be read at the highest speed allowed by the connection between the server and a client.

 

1.11. Connection Type

enum                    TConnectionType   { WAN,  LAN }

 

o   TConnectionType indicates if the client is connected though a local or wide area network. SRM may optimize the access parameters to achieve maximum throughput for the connection type. This will be passed as an input to the srmPrepareToGet, srmPrepareToPut and srmBringOnline functions.

 

 

1.12. Status Codes

enum                    TStatusCode               {    SRM_SUCCESS, 

SRM_FAILURE,

                                                                                SRM_AUTHENTICATION_FAILURE,

                                                                                SRM_AUTHORIZATION_FAILURE,

                                                                                SRM_INVALID_REQUEST,

                                                                                SRM_INVALID_PATH,

                                                                                SRM_FILE_LIFETIME_EXPIRED,

                                                                                SRM_SPACE_LIFETIME_EXPIRED,

SRM_EXCEED_ALLOCATION,

                                                                                SRM_NO_USER_SPACE,

                                                                                SRM_NO_FREE_SPACE,

                                                                                SRM_DUPLICATION_ERROR,

                                                                                SRM_NON_EMPTY_DIRECTORY,

                                                                                SRM_TOO_MANY_RESULTS,

                                                                                SRM_INTERNAL_ERROR,

                                                                                SRM_FATAL_INTERNAL_ERROR,

                                                                                SRM_NOT_SUPPORTED,

                                                                                SRM_REQUEST_QUEUED,

                                                                                SRM_REQUEST_INPROGRESS,

                                                                                SRM_REQUEST_SUSPENDED,

                                                                                SRM_ABORTED,

                                                                                SRM_RELEASED,

                                                                                SRM_FILE_PINNED,

                                                                                SRM_FILE_IN_CACHE,

                                                                                SRM_SPACE_AVAILABLE,

                                                                                SRM_LOWER_SPACE_GRANTED,

                                                                                SRM_DONE,

                                                                                SRM_PARTIAL_SUCCESS,

                                                                                SRM_REQUEST_TIMED_OUT,

SRM_LAST_COPY,

SRM_FILE_BUSY,

SRM_FILE_LOST,

SRM_FILE_UNAVAILABLE,

SRM_CUSTOM_STATUS

}

 

o   SRM_NOT_SUPPORTED is used, in general

·         If a server does not support a method

·         If a server does not support particular optional input parameters

 

 

1.13. Retention Policy Info

typedef                              struct {   TRetentionPolicy              retentionPolicy,

                                                TAccessLatency                                accessLatency

                                } TRetentionPolicyInfo

 

o   TRetentionPolicyInfo is a combined structure to indicate how the file needs to be stored.

o   When both retention policy and access latency are provided, their combination needs to match what SRM supports. Otherwise request will be rejected.

 

1.14. Request Token

 

o   The Request Token assigned by SRM is unique and immutable (non-reusable).  For example, if the date:time is part of the request token it will be immutable.

o   Request tokens are case-sensitive.

o   Request token is valid until the request is completed. However, SRM server may choose to keep the request tokens for a short period of time after the request is completed, and the time period depends on the SRM servers.

 

1.15. User Permission

typedef                              struct {   string                                    userID,

                                                TPermissionMode           mode

} TUserPermission

 

o   userID may represent the associated client’s Distinguished Name (DN) instead of unix style login name.  VOMS role may be included.

 

1.16. Group Permission

typedef                              struct {   string                                    groupID,

                                                TPermissionMode           mode

} TGroupPermission

 

o   groupID may represent the associated client’s Distinguished Name (DN) instead of unix style login name. VOMS role may be included.

 

1.17. Size in Bytes

 

 

1.18. UTC Time

 

 

1.19. Time in Seconds (Lifetime and RequestTime)

 

 

1.20. SURL

 

o   The type definition SURL is represented as anyURI and used for both site URL and the “Storage File Name” (stFN). This was done in order to simplify the notation.  Recall that stFN is the file path/name of the intended storage location when a file is put (or copied) into an SRM controlled space.  Thus, a stFN can be thought of a special case of an SURL, where the protocol is assumed to be “srm” and the machine:port is assumed to be local to the SRM.  For example, when the request srmCopy is made as a pulling case, the source file is specified by a site URL, and the target location can be optionally specified as a stFN.  By considering the stFN a special case of an SURL, a srmCopy takes SURLs as both the source and target parameters.

 

1.21. TURL

 

 

1.22. Return Status

typedef                struct {TStatusCode        statusCode,

                                                string                     explanation

} TReturnStatus

 

1.23. Return Status for SURL

typedef                              struct {anyURI                    surl,

                                                TReturnStatus   status

} TSURLReturnStatus

 

 

1.24. File MetaData

 

typedef                               struct {string                                                     path,   // absolute dir and file path

                                                TReturnStatus                                   status,

                                                unsigned long                                    size,    // 0 if directory

                                                dateTime                                             createdAtTime,

                                                dateTime                                             lastModificationTime,

                                                TFileStorageType                             fileStorageType,

                                                TRetentionPolicyInfo                     retentionPolicyInfo,

                                                TFileLocality                                        fileLocality,

                                                string[]                                                 arrayOfSpaceTokens,

                                                TFileType                                             type,     // Directory or File

int                                                           lifetimeAssigned,

                                                int                                                          lifetimeLeft, // on the SURL

                                                TUserPermission                              ownerPermission,

                                                TGroupPermission                          groupPermission,

                                                TPermissionMode                           otherPermission,

                                                string                                                     checkSumType,

                                                string                                                     checkSumValue,

TMetaDataPathDetail[]                 arrayOfSubPaths     

                                                                                                // optional recursive

} TMetaDataPathDetail

 

o   The TMetaDataPathDetail describes the properties of a file. It is used as an output parameter in srmLs.

o   retentionPolicyInfo indicates the assigned retention policy.

o   fileLocality indicates where the file is located currently in the system.

o   arrayOfSpaceTokens as an array of string indicates where the file is currently located for the client. Only space tokens that the client has authorized to access to read the file must be returned. 

o   Permissions on the SURL represent unix-like permissions: e.g. rwxr--r--.

o   ownerPermission describes the owner ID and owner permission on the SURL.

o   groupPermission describes the group permission with group identifier on the SURL.

o   otherPermission describes the other permission on the SURL.

o   For ACL-like permissions, srmGetPermission must be used.

o   lifetimeAssigned is the total lifetime that is assigned on the SURL. It includes all SURL lifetime extensions if extended.

o   lifetimeLeft is the remaining lifetime on the SURL from the current time until expiration.

·         A negative value (-1) indicates “indefinite” lifetime.

·         Zero (0) indicates that the file is expired.

 

1.25. Space MetaData

typedef                              struct { string                                                      spaceToken,     

                                                TReturnStatus                                   status,

                                                TRetentionPolicyInfo                     retentionPolicyInfo,

string                                                     owner,

                                                unsigned long                                    totalSize,               // best effort

unsigned long                                    guaranteedSize,                                              

unsigned long                                    unusedSize,

                                                int                                                           lifetimeAssigned,

                                                int                                                          lifetimeLeft

} TMetaDataSpace

 

o   TMetaDataSpace is used to describe properties of a space, and is used as an output parameter in srmGetSpaceMetaData.

o   retentionPolicyInfo indicates the information about retention policy and access latency that the space is assigned. retentionPolicyInfo is requested and assigned at the time of space reservation through srmReserveSpace and srmStatusOfReserveSpaceRequest.

o   TMetaDataSpace refers to a single space with retention policy.  It does not include the extra space needed to hold the directory structures, if there is any.

o   lifetimeAssigned is the total lifetime that is assigned to the space. It includes all space lifetime extensions if extended.

o   lifetimeLeft is the remaining lifetime that is left on the space.

 

1.26. Directory Option

typedef                              struct {   Boolean               isSourceADirectory,

                                                Boolean               allLevelRecursive,            // default = false

                                                int                           numOfLevels                     // default = 1

} TDirOption

 

1.27. Extra Info

typedef                              struct {   string                     key,

                                                string                     value

} TExtraInfo

 

o   TExtraInfo is used where additional information is needed, such as for additional information for transfer protocols of TURLs in srmPing, srmGetTransferProtocols, srmStatusOfGetRequest, and srmStatusOfPutRequest.  For example, when it is used for additional information for transfer protocols, the keys may specify access speed, available number of parallelism, and other transfer protocol properties.

o   It is also used where additional information to the underlying storage system is needed, such as for additional information, but not limited to, for storage device, storage login ID, storage login authorization. Formerly, it was TStorageSystemInfo.

 

1.28. Transfer Parameters

typedef                              struct {   TAccessPattern                                 accessPattern,

                                                TConnectionType                            connectionType,

                                                string[]                                                 arrayOfClientNetworks

                                                string[]                                                 arrayOfTransferProtocols

} TTransferParameters

 

o   TTransferParameters is used where arrayOfTransferProtocols was used previously in SRM v2.1.

o   TTransferParameters may be provided optionally in the methods such as srmPrepareToGet, srmBringOnline, srmPrepareToPut and srmReserveSpace. Optional input parameters in TTransferParameters may collide with the characteristics of the space specified. In this case, TTransferParameters as an input parameter must be ignored.

o   File transfer protocols are specified in a preferred order on all SRM transfer functions.

o   arrayOfClientNetworks is a hint of the client IPs that SRM/dCache can use for optimization of its internal storage systems based on the client’s accessible IP addresses.

 

1.29. File Request for srmPrepareToGet

typedef                              struct {   anyURI                                 sourceSURL,

TDirOption                          dirOption,

} TGetFileRequest

 

1.30. File Request for srmPrepareToPut

typedef                              struct {   anyURI                                                 targetSURL ,       // local to SRM 

                                                unsigned long                    expectedFileSize

} TPutFileRequest

 

1.31. File Request for srmCopy

typedef                              struct {   anyURI                                 sourceSURL,

                                                anyURI                                 targetSURL,

TDirOption                          dirOption

} TCopyFileRequest  

 

1.32. Return File Status for srmPrepareToGet

typedef                struct { anyURI                                 sourceSURL,                                      

                                                TReturnStatus                   status,

                                                unsigned long                    fileSize,

                                                int                                           estimatedWaitTime,

int                                           remainingPinTime,

anyURI                                 transferURL,

TExtraInfo[]                                        transferProtocolInfo

} TGetRequestFileStatus

 

o   transferProtocolInfo of type TExtraInfo is added to the TGetRequestFileStatus. This output parameter can be used to provide more information about the transfer protocol so that client can access the TURL efficiently.

o   estimatedWaitTime to be negative value, -1, for unknown.

o   remainingPinTime is the lifetime on the TURL, and 0 means it expired. If a TURL has an indefinite lifetime, then negative value, -1, may be used.

 

1.33. Return File Status for srmBringOnline

typedef                struct { anyURI                                 sourceSURL,                                      

                                                TReturnStatus                   status,

                                                unsigned long                    fileSize,

                                                int                                           estimatedWaitTime,

int                                           remainingPinTime,

} TBringOnlineRequestFileStatus

 

o   estimatedWaitTime to be negative value, -1, for unknown.

o   remainingPinTime is the lifetime on the TURL, and 0 means it expired. If a TURL has an indefinite lifetime, then negative value, -1, may be used.

 

1.34. Return File Status for srmPrepareToPut

typedef                struct { anyURI                                  SURL,

                                                TReturnStatus                   status,

unsigned long                    fileSize,

                                                int                                           estimatedWaitTime,

int                                           remainingPinLifetime  // on TURL

int                                           remainingFileLifetime  // on SURL

anyURI                                 transferURL,

                                                TExtraInfo[]                        transferProtocolInfo

} TPutRequestFileStatus

 

o   transferProtocolInfo of type TExtraInfo is added to the TPutRequestFileStatus to give clients more information about the prepared transfer protocol so that client may use the information to make an efficient access to the prepared TURL through the transfer protocol.

o   estimatedWaitTime to be negative value, -1, for unknown.

o   remainingPinTime is the lifetime on the TURL, and 0 means it expired. If a TURL has indefinite lifetime, then negative value, -1, may be used.

o   remainingFileLifetime is the lifetime on the SURL, and 0 means it expired. If SURL has an indefinite lifetime, then negative value, -1, may be used.

 

1.35. Return File Status for srmCopy

typedef                struct { anyURI                                 sourceSURL,      

                                                anyURI                                 targetSURL,                                       

                                                TReturnStatus                   status,

                                                unsigned long                    fileSize,

                                                int                                           estimatedWaitTime,

int                                           remainingFileLifetime  // on target SURL

} TCopyRequestFileStatus

 

o   estimatedWaitTime to be negative value, -1, for unknown.

o   remainingFileLifetime is the lifetime on the SURL, and 0 means it expired. If SURL has an indefinite lifetime, then negative value, -1, may be used.

 

1.36. Request Summary

typedef                struct {string                                     requestToken,

                                                TReturnStatus                   status,

                                                TRequestType                   requestType,

                                                int                                           totalNumFilesInRequest,

                                                int                                          numOfCompletedFiles,

                                                int                                          numOfWaitingFiles,

                                                int                                          numOfFailedFiles

} TRequestSummary

 

o   numOfWaitingFiles describes the number of files on the queue.

o   numOfFailedFiles describes the number of failed files and aborted files.

o   numOfCompletedFiles describes the number of successfully completed files, number of failed files and number of aborted files.

o   totalNumFilesInRequest describes the numOfWaitingFiles, numOfCompletedFiles, numOfFailedFiles and number of files in progress.

 

1.37. Return Status for SURL

typedef                              struct {   anyURI                                 surl,

                                                TReturnStatus                   status

                                                int                                           fileLifetime,

                                                int                                           pinLifetime,

} TSURLLifetimeReturnStatus

 

o   fileLifetime describes the file lifetime on SURL.

o   pinLifetime describes the pin lifetime on TURL, if applicable.

 

 

1.38. Return File Permissions

typedef                struct {anyURI                                   surl,

                                                TReturnStatus                   status,

                                                TPermissionMode           permission

} TSURLPermissionReturn

 

1.39. Return Permissions on SURL

typedef                               struct {  anyURI                                                 surl,   // both dir and file

                                                TReturnStatus                                   status,

                                                string                                                     owner,

                                                TPermissionMode                           ownerPermission,

TUserPermission[]                          arrayOfUserPermissions,

TGroupPermission[]                       arrayOfGroupPermissions,

TPermissionMode                           otherPermission

} TPermissionReturn

 

o   The TPermissionReturn describes the permission properties of a file. It is used as an output parameter in srmGetPermission.

 

1.40. Return Request Tokens

typedef                              struct {   string                                     requestToken,

                                                dateTime                             createdAtTime

} TRequestTokenReturn

 

1.41. Supported File Transfer Protocol

typedef                struct { string                                     transferProtocol,

                                                TExtraInfo[]                        attributes

} TSupportedTransferProtocol

 

o   transferProtocol (required): Supported transfer protocol. For example, gsiftp, http.

o   attributes: Informational hints for the paired transfer protocol, such how many number of parallel streams can be used, desired buffer size, etc.

 


2. Space Management Functions

 

summary:

                srmReserveSpace

                srmStatusOfReserveSpaceRequest

                srmReleaseSpace

                srmUpdateSpace

srmGetSpaceMetaData

srmChangeSpaceForFiles

srmStatusOfChangeSpaceForFilesRequest

srmExtendFileLifeTimeInSpace

srmPurgeFromSpace

srmGetSpaceTokens

 

2.1. srmReserveSpace

               

This function is used to reserve a space in advance for the upcoming requests to get some guarantee on the file management. Asynchronous space reservation may be necessary for some SRMs to serve many concurrent requests.

 

2.1.1. Parameters

 

                In:           string                                                     authorizationID,

String                                                    userSpaceTokenDescription,

                                TRetentionPolicyInfo                     retentionPolicyInfo,

unsigned long                                    desiredSizeOfTotalSpace,

unsigned long                                    desiredSizeOfGuaranteedSpace,

int                                                           desiredLifetimeOfReservedSpace,

unsigned long []                               arrayOfExpectedFileSizes,

TExtraInfo[]                                        storageSystemInfo,

TTransferParameters                     transferParameters

 

                Out:       TReturnStatus                                   returnStatus,

string                                                     requestToken,

                                int                                                           estimatedProcessingTime,

                                TRetentionPolicyInfo                     retentionPolicyInfo,

unsigned long                                    sizeOfTotalReservedSpace,         // best effort

unsigned long                                    sizeOfGuaranteedReservedSpace,

int                                                           lifetimeOfReservedSpace,  

string                                                    spaceToken

 

 

2.1.2. Notes on the Behavior

a)      Input parameter userSpaceTokenDescription is case-sensitive. SRM server is expected to keep it as client provides. It can be reused by the client. srmGetSpaceTokens will return all the space tokens that have the userSpaceTokenDescription.

b)      If the input parameter desiredLifetimeOfReservedSpace is not provided, the lifetime of the reserved space may be set to “infinite (indefinite)” by default.

c)       If particular values of the input parameter retentionPolicyInfo cannot be satisfied by the SRM server, SRM_NOT_SUPPORTED or SRM_NO_FREE_SPACE must be returned.

d)      Asynchronous space reservation may be necessary for some SRMs to serve many concurrent requests. In such case, request token must be returned, and space token must not be assigned and returned until space reservation is completed, to prevent the usage of the space token in other interfaces before the space reservation is completed. If the space reservation can be done immediately, request token must not be returned.

e)      When asynchronous space reservation is necessary, the returned status code should be SRM_REQUEST_QUEUED.

f)       Input parameter arrayOfExpectedFileSize is a hint that SRM server can use to reserve consecutive storage sizes for the request. At the time of space reservation, if space accounting is done only at the level of the total size, this hint would not help. In such case, the expected file size at the time of srmPrepareToPut will describe how much consecutive storage size is needed for the file. However, some SRMs may get benefits from these hints to make a decision to allocate some blocks in some specific devices.

g)      Optional input parameter storageSystemInfo is needed in case the underlying storage system requires additional security information.

h)      SRM may return its default space size and lifetime if not requested by the client. SRM may return SRM_INVALID_REQUEST if SRM does not support default space sizes.

i)        If input parameter desiredSizeOfTotalSpace is not specified, the SRM will return its default space size.

j)        Output parameter estimateProcessingTime is used to indicate the estimation time to complete the space reservation request, when known.

k)      Output parameter sizeOfTotalReservedSpace is in best effort bases. For guaranteed space size, sizeOfGuaranteedReservedSpace should be checked. These two numbers may match, depending on the storage systems.

l)        Output parameter spaceToken is a reference handle of the reserved space.

m)    If an operation is successful (SRM_SUCCESS or SRM_LOWER_SPACE_GRANTED), sizeOfGuaranteedReservedSpace, lifetimeOfReservedSpace and spaceToken are required to return to the client.

n)      Optional input parameters in TTransferParameters may collide with the characteristics of the space specified. In this case, TTransferParameters as an input parameter must be ignored.

 

2.1.3. Return Status Code

SRM_SUCCESS

§  successful request completion. Space is reserved successfully as the client requested.

SRM_REQUEST_QUEUED

§  successful request submission and acceptance. Request token must be returned, and space token must not be assigned and returned.

SRM_REQUEST_INPROGRESS

§  the request is being processed.

SRM_LOWER_SPACE_GRANTED

§  successful request completion, but lower space size is allocated than what the client requested

SRM_AUTHENTICATION_FAILURE

§  SRM server failed to authenticate the client

SRM_AUTHORIZATION_FAILURE

§  client is not authorized to reserve space

SRM_INVALID_REQUEST

§  If space size or lifetime is not requested by the client, and SRM does not support default values for space size or lifetime.

§  input parameters are invalid.

SRM_NO_USER_SPACE

§  SRM server does not have enough user space for the client for client to request to reserve.

SRM_NO_FREE_SPACE

§  SRM server does not have enough free space for client to request to reserve.

§  SRM server does not have enough free space for a particular retentionPolicyInfo

SRM_EXCEED_ALLOCATION

§  SRM server does not have enough space for the client to fulfill the request because the client request needs more than the allocated space  quota for the client.

SRM_INTERNAL_ERROR

§  SRM has an internal transient error, and client may try again.

SRM_FAILURE

§  any other request failure. Explanation needs to be filled for details.

SRM_NOT_SUPPORTED

§  function is not supported in the SRM server

§  specific values of the input parameter retentionPolicyInfo is not supported by the SRM

§  any input parameter is not supported in the SRM server

§  a particular type of an input parameter is not supported in the SRM server

 

 

2.2. srmStatusOfReserveSpaceRequest

 

This function is used to check the status of the previous request to srmReserveSpace, when asynchronous space reservation was necessary with the SRM. Request token must have been provided in response to the srmReserveSpace.

 

2.2.1. Parameters

 

                In:           string                                                     authorizationID,

                                string                                                     requestToken

 

                Out:       TReturnStatus                                   returnStatus,

int                                                           estimatedProcessingTime,

                                TRetentionPolicyInfo                     retentionPolicyInfo,

unsigned long                                    sizeOfTotalReservedSpace,

unsigned long                                    sizeOfGuaranteedReservedSpace,

int                                                           lifetimeOfReservedSpace,  

string                                                     spaceToken

 

 

2.2.2. Notes on the Behavior

a)      If the space reservation is not completed yet, estimateProcessingTime is returned when known. The returned status code in such case should be SRM_REQUEST_QUEUED.

b)      See notes for srmReserveSpace for descriptions for output parameters.

c)       If an operation is successful (SRM_SUCCESS or SRM_LOWER_SPACE_GRANTED), sizeOfGuaranteedReservedSpace, lifetimeOfReservedSpace and spaceToken are required to return to the client.

 

2.2.3. Return Status Code

SRM_REQUEST_QUEUED

§  successful request submission and the request is still on the queue to be served.

SRM_REQUEST_INPROGRESS

§  the request is being processed.

SRM_LOWER_SPACE_GRANTED

§  successful request completion, but lower space size is allocated than what the client requested

SRM_SUCCESS

§  successful request completion. Space is reserved successfully as the client requested.

SRM_AUTHENTICATION_FAILURE

§  SRM server failed to authenticate the client

SRM_AUTHORIZATION_FAILURE

§  client is not authorized to reserve space

SRM_INVALID_REQUEST

§  requestToken does not refer to an existing known request in the SRM server.

SRM_EXCEED_ALLOCATION

§  SRM server does not have enough space for the client to fulfill the request because the client request needs more than the allocated space for the client.

SRM_NO_USER_SPACE

§  SRM server does not have enough user space for the client for the client for client to request to reserve.

SRM_NO_FREE_SPACE

§  SRM server does not have enough free space for the client for client to request to reserve.

§  SRM server does not have enough free space for a particular retentionPolicyInfo

SRM_REQUEST_SUSPENDED

§  request is suspended.

SRM_INTERNAL_ERROR

§  SRM has an internal transient error, and client may try again.

SRM_FAILURE

§  any other request failure. Explanation needs to be filled for details.

SRM_NOT_SUPPORTED

§  function is not supported in the SRM server

§  any input parameter is not supported in the SRM server

§  a particular type of an input parameter is not supported in the SRM server

 

 

2.3. srmReleaseSpace

 

srmReleaseSpace() releases an occupied space.

 

2.3.1. Parameters

 

                In:           string                                     authorizationID,

string                                     spaceToken,

TExtraInfo[]                        storageSystemInfo,

                                Boolean                               forceFileRelease

 

Out:       TReturnStatus                   returnStatus

 

 

2.3.2. Notes on the Behavior

a)      forceFileRelease is false by default.  This means that the space will not be released if it has files that are still pinned in the space.  To release the space regardless of the files it contains and their status forceFileRelease must be specified to be true.

b)      When space is releasable and forceFileRelease is true, all the files in the space are released, even in OUTPUT or CUSTODIAL retention quality space.

c)       srmReleaseSpace may not complete right away because of the lifetime of existing files in the space.  When space is released, the files in that space are treated according to their types: If file storage types are permanent, keep them until further operation such as srmRm is issued by the client. If file storage types are durable, perform necessary actions at the end of their lifetime. If file storage types are volatile, release those files at the end of their lifetime.

d)      If space is being released with forceFileRelease option while SURLs are being created with srmPrepareToPut or srmCopy, the file is removed and SRM_INVALID_PATH must be returned by the srmPutDonesrmStatusOfPutRequest, or srmStatusOfCopyRequest when the file is volatile. If the file is permanent type, the file is moved to the default space, and the space would be successfully released. The subsequent srmPutDone, srmStatusOfPutRequest, or srmStatusOfCopyRequest would be successful.

e)      If space is being released without forceFileRelease option while SURLs are being created with srmPrepareToPut or srmCopy, SRM_FAILURE must be returned in srmReleaseSpace.

f)       When a "replica" quality space is expired on its lifetime, all files inside must be expired (by definition, file lifetimes are less than and equal to the remaining lifetime of the space). After the space is expired, the space that is associated with the space token no longer exists, along with all files inside - meaning their SURLs disappear from the file system or reflect the expired lifetime.

 

2.3.3. Return Status Code

SRM_SUCCESS

§  successful request completion. Space is successfully released.

SRM_AUTHENTICATION_FAILURE

§  SRM server failed to authenticate the client

SRM_AUTHORIZATION_FAILURE

§  client is not authorized to release the space that is associated with the spaceToken

SRM_INVALID_REQUEST

§  spaceToken does not refer to an existing known space in the SRM server.

SRM_INTERNAL_ERROR

§  SRM has an internal transient error, and client may try again.

SRM_NOT_SUPPORTED

§  forceFileRelease is not supported

§  function is not supported

SRM_FAILURE

§  space still contains pinned files.

§  space associated with space is already released.

§  any other request failure. Explanation needs to be filled for details.

 

 

2.4.  srmUpdateSpace

 

srmUpdateSpace is to resize the space and/or extend the lifetime of a space. Asynchronous operation may be necessary for some SRMs to serve many concurrent requests.

 

2.4.1. Parameters

 

                In:           string                                                     authorizationID,

string                                                     spaceToken,

unsigned long                                    newSizeOfTotalSpaceDesired,

unsigned long                                    newSizeOfGuaranteedSpaceDesired,

int                                                           newLifeTime,

TExtraInfo[]                                        storageSystemInfo

 

                Out:       TReturnStatus                                   returnStatus,

string                                                     requestToken,

unsigned long                                    sizeOfTotalSpace,            // best effort

unsigned long                                    sizeOfGuaranteedSpace,                            

int                                                           lifetimeGranted

 

2.4.2. Notes on the Behavior

a)      If neither size nor lifetime is provided in the input parameters, then the request will be failed, and SRM_INVALID_REQUEST must be returned. The existing values must not be changed.

b)      newSize is the new actual size of the space.

c)       newLifetime is the new lifetime requested regardless of the previous lifetime.  It might even be shorter than the remaining lifetime at the time of the call. It is relative to the calling time. Lifetime will be set from the calling time for the specified period.

d)      Output parameter, lifetimeGranted is the new lifetime granted regardless of the previous lifetime.  It might even be shorter than the previous lifetime. It is relative to the calling time.

 

2.4.3. Return Status Code

SRM_SUCCESS

§  successful request completion. Space is successfully updated as the client requested.

SRM_ REQUEST_QUEUED

§  successful request submission and acceptance. Request token must be returned.

SRM_LOWER_SPACE_GRANTED

§  successful request completion, but lower space size is allocated than what the client requested

SRM_AUTHENTICATION_FAILURE

§  SRM server failed to authenticate the client

SRM_AUTHORIZATION_FAILURE

§  client is not authorized to update the space that is associated with the spaceToken

SRM_SPACE_LIFETIME_EXPIRED

§  lifetime of the space that is associated with the spaceToken is already expired.

SRM_INVALID_REQUEST

§  spaceToken does not refer to an existing known space in the SRM server.

§  input parameter size or time is not provided.

SRM_EXCEED_ALLOCATION

§  SRM server does not have enough space for the client to fulfill the request because the client request has more than the allocated space for the client.

SRM_NO_USER_SPACE

§  SRM server does not have enough space for the client to fulfill the request

SRM_NO_FREE_SPACE

§  SRM server does not have enough free space to fulfill the request

SRM_INTERNAL_ERROR

§  SRM has an internal transient error, and client may try again.

SRM_FAILURE

§  New requested size is less than currently used space.

§  any other request failure. Explanation needs to be filled for details.

SRM_NOT_SUPPORTED

§  function is not supported

 

 

2.5. srmStatusOfUpdateSpaceRequest

 

This function is used to check the status of the previous request to srmUpdateSpace, when asynchronous space update was necessary with the SRM. Request token must have been provided in response to the srmUpdateSpace.

 

2.5.1. Parameters

 

                In:           string                                                     authorizationID,

string                                                     requestToken

 

                Out:       TReturnStatus                                   returnStatus,

unsigned long                                    sizeOfTotalSpace,            // best effort

unsigned long                                    sizeOfGuaranteedSpace,                            

int                                                           lifetimeGranted

 

2.5.2. Notes on the Behavior

a)      Output parameters for sew sizes are the new actual sizes of the space.

b)      Output parameter, lifetimeGranted is the new lifetime granted regardless of the previous lifetime.  It might even be shorter than the previous lifetime. It is relative to the calling time.

 

2.5.3. Return Status Code

SRM_REQUEST_QUEUED

§  successful request submission and the request is still on the queue to be served.

SRM_REQUEST_INPROGRESS

§  the request is being processed.

SRM_SUCCESS

§  successful request completion. Space is successfully updated as the client requested.

SRM_LOWER_SPACE_GRANTED

§  successful request completion, but lower space size is allocated than what the client requested

SRM_AUTHENTICATION_FAILURE

§  SRM server failed to authenticate the client

SRM_AUTHORIZATION_FAILURE

§  client is not authorized to update the space that is associated with the spaceToken

SRM_SPACE_LIFETIME_EXPIRED

§  lifetime of the space that is associated with the spaceToken is already expired.

SRM_INVALID_REQUEST

§  spaceToken does not refer to an existing known space in the SRM server.

§  input parameter size or time is not provided.

SRM_EXCEED_ALLOCATION

§  SRM server does not have enough space for the client to fulfill the request because the client request has more than the allocated space for the client.

SRM_NO_USER_SPACE

§  SRM server does not have enough space for the client to fulfill the request

SRM_NO_FREE_SPACE

§  SRM server does not have enough free space to fulfill the request

SRM_REQUEST_SUSPENDED

§  request is suspended.

SRM_INTERNAL_ERROR

§  SRM has an internal transient error, and client may try again.

SRM_FAILURE

§  New requested size is less than currently used space.

§  any other request failure. Explanation needs to be filled for details.

SRM_NOT_SUPPORTED

§  function is not supported

 

 

2.6. srmGetSpaceMetaData

 

This function is used to get information of a space.  Space token must be provided, and space tokens are returned upon a completion of a space reservation through srmReserveSpace or srmStatusOfReserveSpaceRequest.  

 

2.6.1. Parameters

 

                In:           string                                     authorizationID,

string[]                                 arrayOfSpaceTokens

 

                Out:       TReturnStatus                   returnStatus,

TMetaDataSpace[]          arrayOfSpaceDetails

 

2.6.2. Notes on the Behavior

a)      Output parameters unusedSize in TMetaDataSpace returns 0 if there is no space left in the allocated space.

b)      When clients use more space than allocated, clients get warned to accommodate their files in the spaces or update the space before running out. SRM

 

2.6.3. Return Status Code

For request level return Status,

SRM_SUCCESS

§  successful request completion. Information of all requested spaces are returned successfully.

SRM_PARTIAL_SUCCESS

§  Request is completed. Information of some requested spaces are returned successfully, and some are failed to be returned.

SRM_AUTHENTICATION_FAILURE

§  SRM server failed to authenticate the client

SRM_AUTHORIZATION_FAILURE

§  client is not authorized to request space information

SRM_TOO_MANY_RESULTS

§  Request produced too many results that SRM server cannot handle.

SRM_INVALID_REQUEST

§  arrayOfSpaceToken is empty.

SRM_INTERNAL_ERROR

§  SRM has an internal transient error, and client may try again.

SRM_FAILURE

§  All space requests are failed.

§  any other request failure. Explanation needs to be filled for details.

SRM_NOT_SUPPORTED

§  function is not supported in the SRM server

 

For space level return Status,

SRM_SUCCESS

§  successful request completion for the spaceToken. Space information is successfully returned.

SRM_AUTHORIZATION_FAILURE

§  client is not authorized to request information on the space that is associated with the spaceToken

SRM_INVALID_REQUEST

§  spaceToken does not refer to an existing known space in the SRM server.

SRM_SPACE_LIFETIME_EXPIRED

§  The life time on the space that is associated with the spaceToken has expired

SRM_EXCEED_ALLOCATION

§  Space that is associated with spaceToken has no more space left.

SRM_FAILURE

§  any other request failure. Explanation needs to be filled for details.

 

 

2.7. srmChangeSpaceForFiles

 

This function is used to change the space property of files to another space property by specifying target space tokens.  All files specified by SURLs will have a new space token. SURLs must not be changed. New space token may be acquired from srmReserveSpace.  Asynchronous operation may be necessary for some SRMs, and in such case, request token is returned for later status inquiry. There is no default behavior when target space token is not provided. In such case, the request will be rejected, and the return status must be SRM_INVALID_REQUEST.

 

2.7.1. Parameters

 

                In:           string                                                     authorizationID,

                                anyURI []                                             arrayOfSURLs,

                                string                                                     targetSpaceToken,

                                TExtraInfo[]                                        storageSystemInfo

 

                Out:       TReturnStatus                                   returnStatus,

string                                                     requestToken,

                                int                                                           estimatedProcessingTime,

                                TSURLReturnStatus []                    arrayOfFileStatuses

                               

 

2.7.2. Notes on the Behavior

a)      When space transition is completed successfully, SRM_SUCCESS must be returned for each SURL.

b)      For any forbidden transition by the SRM implementation, SRM_INVALID_REQUEST must be returned. It includes changing spaces on SURLs that statuses are SRM_FILE_BUSY.

c)       Asynchronous operation may be necessary for some SRMs to serve many concurrent requests. In such case, request token must be returned. If the request can be completed immediately, request token must not be returned.

d)      When asynchronous operation is necessary, the returned status code should be SRM_REQUEST_QUEUED, and arrayOfFileStatuses may not be filled and returned.

e)      All files specified in arrayOfSURLs will be moved to the space associated with targetSpaceToken.

f)       When target space token is used, space allocation for a new space token must be done explicitly by the client before using this function.

g)      If a directory path is provided, then the effect is recursive for all files in the directory.

h)      Space de-allocation may be necessary in some cases, and it must be done by the client explicitly after this operation completes. The status can be checked by srmStatusOfChangeSpaceForFilesRequest.

i)        When a space is successfully changed for a file from one space to another, it will either retain its remaining lifetime, or the lifetime will be reduced to that of the target space, whichever is the lesser.

j)        If the target space is only large enough to transfer a subset of the files, the request will continue taking place until the target space cannot hold any more files, and the request must be failed.  The status of the request must return an error of SRM_EXCEED_ALLOCATION in such case.

 

2.7.3. Return Status Code

For request level return status,

SRM_SUCCESS

§  All file requests are successfully completed. All SURLs have new targetSpaceToken.

SRM_PARTIAL_SUCCESS

§  All requests are completed. Some SURL requests have new targetSpaceToken, and some SURL requests are failed to have new targetSpaceToken. Details are on the files status.

SRM_ REQUEST_QUEUED

§  request is submitted and accepted. requestToken must be returned.

§  The status can be checked by srmStatusOfChangeSpaceForFilesRequest.

SRM_ REQUEST_INPROGRESS

§  The request is being processed. Some files are still queued, and some files are completed in space transition.

SRM_AUTHENTICATION_FAILURE

§  SRM server failed to authenticate the client

SRM_AUTHORIZATION_FAILURE

§  client is not authorized to change the file types

SRM_INVALID_REQUEST

§  SURL is empty.

§  targetSpaceToken is empty.

§  targetSpaceToken does not refer to an existing space in the SRM server.

§  targetSpaceToken refers to a forbidden transition by the SRM implementation.

SRM_SPACE_LIFETIME_EXPIRED

§  target space that is associated with targetSpaceToken has an expired lifetime.

SRM_EXCEED_ALLOCATION

§  target space that is associated with targetSpaceToken is not enough to hold all SURLs.

SRM_INTERNAL_ERROR

§  SRM has an internal transient error, and client may try again.

SRM_FAILURE

§  any other request failure. Explanation needs to be filled for details.

SRM_NOT_SUPPORTED

§  function is not supported in the SRM

§  any input parameter is not supported in the SRM server

§  a particular type of an input parameter is not supported in the SRM server

 

For file level return status,

SRM_SUCCESS

§  successful request completion for the SURL. The SURL has a new targetSpaceToken.

SRM_ REQUEST_QUEUED

§  file request is on the queue.

SRM_ REQUEST_INPROGRESS

§  file request is being processed.

SRM_INVALID_PATH

§  SURL does not refer to an existing file

SRM_AUTHORIZATION_FAILURE

§  client is not authorized to change the space for the file that is associated with the SURL

SRM_INVALID_REQUEST

§  targetSpaceToken refers to a forbidden transition for the particular SURL by the SRM implementation.

§  The status of SURL is SRM_FILE_BUSY.

SRM_EXCEED_ALLOCATION

§  target space that is associated with targetSpaceToken is not enough to hold SURL.

SRM_FILE_LOST

§  the requested file with the SURL is permanently lost.

SRM_FILE_BUSY

§  client requests for files which there is an active srmPrepareToPut (no srmPutDone is not yet called) for.

§  The requested file with the SURL is being used by other clients.

SRM_FILE_UNAVAILABLE

§  the requested file with the SURL is temporarily unavailable.

SRM_FAILURE

§  All file requests are failed.

§  any other request failure. Explanation needs to be filled for details.

 

 

2.8. srmStatusOfChangeSpaceForFilesRequest

 

This function is used to check the status of the previous request to srmChangeSpaceForFiles, when asynchronous operation was necessary in the SRM. Request token must have been provided in response to the srmChangeSpaceForFiles.

 

2.8.1. Parameters

 

                In:           string                                                     authorizationID,

                                string                                                     requestToken

 

                Out:       TReturnStatus                                   returnStatus

int                                                           estimatedProcessingTime,

TSURLReturnStatus []                    arrayOfFileStatuses

 

2.8.2. Notes on the Behavior

a)      When space transition is completed successfully, SRM_SUCCESS must be returned for each SURL.

b)      If changing space is not completed, estimateProcessingTime is returned when known.

c)       If all files are still in the queue and none of the files are completed in changing space, the returned status code should be SRM_REQUEST_QUEUED.

d)      If some files are queued, and some files are completed in changing space, SRM_REQUEST_INPROGRESS must be returned as the return status code. Each file should have its own status code.

e)      If the target space is only large enough to transfer a subset of the files, the request will continue taking place until the target space cannot hold any more files, and the request must be failed.  The status of the request must return an error of SRM_EXCEED_ALLOCATION in such case.

 

2.8.3. Return Status Code

For request level return status,

SRM_SUCCESS

§  All file requests are successfully completed. All SURLs have new targetSpaceToken.

SRM_PARTIAL_SUCCESS

§  All requests are completed. Some SURL requests have new targetSpaceToken, and some SURL requests are failed to have new targetSpaceToken. Details are on the files status.

SRM_ REQUEST_QUEUED

§  Request submission was successful and the entire request is still on the queue.

SRM_ REQUEST_INPROGRESS

§  Some files are still queued, and some files are completed in space transition.

SRM_AUTHENTICATION_FAILURE

§  SRM server failed to authenticate the client

SRM_AUTHORIZATION_FAILURE

§  client is not authorized to change the file types

SRM_INVALID_REQUEST

§  requestToken does not refer to an existing known request in the SRM server.

§  targetSpaceToken refers to a forbidden transition by the SRM implementation.

SRM_SPACE_LIFETIME_EXPIRED

§  target space that is associated with targetSpaceToken has an expired lifetime.

SRM_EXCEED_ALLOCATION

§  target space that is associated with targetSpaceToken is not enough to hold SURLs.

SRM_REQUEST_SUSPENDED

§  request is suspended.

SRM_INTERNAL_ERROR

§  SRM has an internal transient error, and client may try again.

SRM_FAILURE

§  All file requests are failed.

§  any other request failure. Explanation needs to be filled for details.

SRM_NOT_SUPPORTED

§  function is not supported in the SRM

§  any input parameter is not supported in the SRM server

§  a particular type of an input parameter is not supported in the SRM server

 

For file level return status,

SRM_SUCCESS

§  successful request completion for the SURL. The SURL has a new targetSpaceToken.

SRM_ REQUEST_QUEUED

§  file request is on the queue.

SRM_ REQUEST_INPROGRESS

§  file request is being processed.

SRM_INVALID_PATH

§  SURL does not refer to an existing file request

SRM_AUTHORIZATION_FAILURE

§  client is not authorized to change the space for the file that is associated with the SURL

SRM_INVALID_REQUEST

§  targetSpaceToken refers to a forbidden transition for the particular SURL by the SRM implementation.

§  The status of SURL is SRM_FILE_BUSY.

SRM_EXCEED_ALLOCATION

§  target space that is associated with targetSpaceToken is not enough to hold SURL.

SRM_REQUEST_SUSPENDED

§  file request is suspended.

SRM_FILE_LOST

§  the requested file with the SURL is permanently lost.

SRM_FILE_BUSY

§  client requests for files which there is an active srmPrepareToPut (no srmPutDone is not yet called) for.

§  The requested file with the SURL is being used by other clients.

SRM_FILE_UNAVAILABLE

§  the requested file with the SURL is temporarily unavailable.

SRM_FAILURE

§  any other request failure. Explanation needs to be filled for details.

 

 

2.9. srmExtendFileLifeTimeInSpace

 

This function is used to extend lifetime of the files (SURLs) in a space.

 

2.9.1. Parameters

 

                In:           string                                                     authorizationID,

string                                                     spaceToken,

                                anyURI []                                             arrayOfSURLs,

                                int                                                           newLifeTime

 

                Out:       TReturnStatus                                   returnStatus,

                                TSURLLifetimeReturnStatus []    arrayOfFileStatuses

 

 

2.9.2. Notes on the Behavior

a)      arrayOfSURLs are optional. When SURLs are not provided, all files in the space must have the new extended lifetimes.

b)      newLifeTime is relative to the calling time. Lifetime will be set from the calling time for the specified period.

c)       The new file lifetime, newLifeTime must not exceed the remaining lifetime of the space.

d)      The number of lifetime extensions may be limited by SRM according to its policies.

e)      If original lifetime is longer than the requested one, then the new requested one will be assigned.

f)       If newLifeTime is not specified, the SRM does not change the lifetime.

g)      If input parameters newLifeTime request exceed the remaining lifetime of the space, then SRM_SUCCESS is returned at the request and file level, and TSURLLifetimeReturnStatus contains the remaining lifetime.

h)      Lifetime extension must fail on SURLs when their status is SRM_FILE_BUSY.

i)        This method applied only to SURLs, and output parameter pinLifetime in TSURLLifetimeReturnStatus must be null.

 

2.9.3. Return Status Code

For request level return status,

SRM_SUCCESS

§  All requests are successfully completed. All SURLs have a new extended lifetime.

SRM_PARTIAL_SUCCESS

§  All requests are completed. Some SURLs have a new extended lifetime, and some SURLS have failed. Details are on the files status.

SRM_AUTHENTICATION_FAILURE

§  SRM server failed to authenticate the client

SRM_AUTHORIZATION_FAILURE

§  client is not authorized to extend lifetime of files in the space specified by the space token.

SRM_INVALID_REQUEST

§  spaceToken is empty.

§  spaceToken does not refer to an existing known space in the SRM server.

SRM_SPACE_LIFETIME_EXPIRED

§  lifetime of the space that is associated with the spaceToken is already expired.

SRM_INTERNAL_ERROR

§  SRM has an internal transient error, and client may try again.

SRM_FAILURE

§  All file requests updating lifetimes in a space are failed.

§  any other request failure. Explanation needs to be filled for details.

SRM_NOT_SUPPORTED

§  function is not supported in the SRM server

§  any input parameter is not supported in the SRM server

§  a particular type of an input parameter is not supported in the SRM server

 

For file level return status,

SRM_SUCCESS

§  successful request completion for the SURL. The SURL has a new extended lifetime.

SRM_INVALID_PATH

§  SURL does not refer to an existing file request

§  SURL does not refer to an existing file request that is associated with the space token

SRM_AUTHORIZATION_FAILURE

§  client is not authorized to extend the lifetime for the file that is associated with the SURL

SRM_FILE_LOST

§  the requested file is permanently lost.

SRM_FILE_UNAVAILABLE

§  the requested file is temporarily unavailable.

SRM_FILE_LIFETIME_EXPIRED

§  the requested file is expired already.

SRM_FAILURE

§  any other request failure. Explanation needs to be filled for details.

 

 

2.10. srmPurgeFromSpace

 

This function is used when removing files from the given space is needed. Difference from srmReleaseFiles and srmAbortFiles is that srmPurgeFromSpace is not associated with a request. This function must not remove the SURLs, but only the "copies" or "states" of the SURLs.  srmRm must be used to remove SURLs.

 

2.10.1. Parameters

 

                In:           string                                                     authorizationID

                                anyURI []                                             arrayOfSURLs

                                string                                                     spaceToken,

                                TExtraInfo[]                                        storageSystemInfo

 

                Out:       TReturnStatus                                   returnStatus,

TSURLReturnStatus[]                     arrayOfFileStatuses

 

 

2.10.2. Notes on the Behavior

a)      If the specified SURL is the only remaining copy of the file in the storage system, SRM_LAST_COPY must be returned. To remove the last copy of the SURL, srmRm may be used.

b)      If the client has an administers role that SRM server can accept in an understandable form, this request will forcefully release the pins owned by the group, and remove the “copy” (or “state”) of the file.

c)       In most cases, all pins on files that are associated with the client will be released. In such cases, files may still be pinned by others and SRM_FILE_BUSY will be returned.

d)      SRM will remove only the “copies” (or “state”) of the SURLs associated with the space token.

 

2.10.3. Return Status Code

For request level return status,

SRM_SUCCESS

§  All requests are successfully completed. All SURLs are purged from the space specified by the spaceToken.

SRM_PARTIAL_SUCCESS

§  All requests are completed. Some SURLs are successfully purged from the space specified by the spaceToken, and some SURLs are failed to be purged from the space specified by the spaceToken. Details are on the files status.

SRM_AUTHENTICATION_FAILURE

§  SRM server failed to authenticate the client

SRM_AUTHORIZATION_FAILURE

§  client is not authorized to clean up the space that is associated with spaceToken

SRM_INVALID_REQUEST

§  arrayOfSURLs is empty.

§  spaceToken is empty.

§  spaceToken does not refer to an existing known space in the SRM server.

SRM_INTERNAL_ERROR

§  SRM has an internal transient error, and client may try again.

SRM_FAILURE

§  All file requests are failed.

§  any other request failure. Explanation needs to be filled for details.

SRM_NOT_SUPPORTED

§  function is not supported in the SRM server

 

For file level return Status,

SRM_SUCCESS

§  successful request completion for the SURL. SURL is purged from the space specified by the spaceToken.

SRM_INVALID_PATH

§  SURL does not refer to an existing file

§  SURL does not refer to an existing file that is associated with the space token

SRM_AUTHORIZATION_FAILURE

§  Client is not authorized to purge SURL in the space that is associated with spaceToken

SRM_FILE_LOST

§  the request file is permanently lost.

SRM_FILE_BUSY

§  client requests for files which there is an active srmPrepareToPut (no srmPutDone is not yet called) for.

§  The requested file is used by other clients.

SRM_FILE_UNAVAILABLE

§  the requested file is temporarily unavailable.

SRM_LAST_COPY

§  the requested file is the last copy and will not be purged from the space. srmRm must be used to remove the last copy.

SRM_FAILURE

§  any other request failure. Explanation needs to be filled for details.

 

 

2.11. srmGetSpaceTokens

 

srmGetSpaceTokens() returns space tokens for currently allocated spaces.

 

2.11.1. Parameters

 

                In:           string                                     userSpaceTokenDescription,

                                string                                     authorizationID

 

                Out:       TReturnStatus                   returnStatus

string[]                                 arrayOfSpaceTokens

 

 

2.11.2. Notes on the Behavior

a)      If userSpaceTokenDescription is null, returns all space tokens this user owns.

b)      Input parameter userSpaceTokenDescription is case-sensitive. SRM server is expected to keep it as client provides. It can be reused by the client. srmGetSpaceTokens will return all the space tokens that have the userSpaceTokenDescription.

c)       If the user assigned the same name to multiple space reservations, he may get back multiple space tokens.

 

2.11.3. Return Status Code

SRM_SUCCESS

§  All requests are successfully completed. Space tokens are returned successfully.

SRM_AUTHENTICATION_FAILURE

§  SRM server failed to authenticate the client

SRM_AUTHORIZATION_FAILURE

§  client is not authorized to request spaceTokens associated with the userSpaceTokenDescription

SRM_INVALID_REQUEST

§  userSpaceTokenDescription does not refer to an existing space description.

SRM_INTERNAL_ERROR

§  SRM has an internal transient error, and client may try again.

SRM_FAILURE

§  any other request failure. Explanation needs to be filled for details.

SRM_NOT_SUPPORTED

§  function is not supported in the SRM server

 

 


3. Permission Functions

 

summary:

srmSetPermission

srmCheckPermission

srmGetPermission

 

 

3.1. srmSetPermission

 

srmSetPermission is to set permission on local SURL.

 

3.1.1. Parameters

 

                In:           string                                     authorizationID,

anyURI                                 SURL,   

TPermissionType             permissionType,

TPermissionMode           ownerPermission,

TUserPermission[]          arrayOfUserPermissions,

TGroupPermission[]       arrayOfGroupPermissions,

TPermissionMode           otherPermission,

                                TExtraInfo[]                        storageSystemInfo

 

Out:       TReturnStatus                   returnStatus

 

3.1.2. Notes on the Behavior

a)      Applies to both dir and file.

b)      Support for srmSetPermission is optional.

c)       User permissions are provided in order to support dynamic user-level permission assignment similar to Access Control Lists (ACLs).

d)      Permissions can be assigned to set of users and sets of groups, but only a single owner.

e)      In this version, SRMs do not provide any group operations (setup, modify, remove, etc.)

f)       Groups are assumed to be set up before srmSetPermission is used.

g)      If TPermissionType is ADD or CHANGE, and TPermissionMode is null, then it is assumed that TPermissionMode is READ only.

h)      If TPermissionType is REMOVE, then the TPermissionMode is ignored.

i)        if TPermissionType is CHANGE, but it is being applied to a [user|group] which currently does not have permissions set up for it, then the request works as ADD. It follows the setfacl: Adds one or more new ACL entries to the  file,  and/or modifies one or more existing ACL entries on the file. If an entry already exists for a specified uid or gid, the specified permissions will replace the current permissions. If an entry does not exist for the specified uid or gid, an entry will be created.

j)        srmSetPermission will modify permissions on SURLs even if the statuses of the SURLs are SRM_FILE_BUSY.

 

3.1.3. Return Status Code

SRM_SUCCESS

§  successful request completion. SURL has a new permission.

SRM_AUTHENTICATION_FAILURE

§  SRM server failed to authenticate the client

SRM_AUTHORIZATION_FAILURE

§  client is not authorized to set permissions

§  client is not authorized to set permissions on the SURL

SRM_INVALID_PATH

§  SURL does not refer to an existing known path

SRM_INVALID_REQUEST

§  Permissions are provided incorrectly

SRM_INTERNAL_ERROR

§  SRM has an internal transient error, and client may try again.

SRM_FAILURE

§  any other request failure. Explanation needs to be filled for details.

SRM_NOT_SUPPORTED

§  function is not supported in the SRM server

§  any input parameter is not supported in the SRM server

§  a particular type of an input parameter is not supported in the SRM server

 

 

3.2. srmCheckPermission

               

srmCheckPermission is used to check the client permissions on the SURLs. It only checks for the client for authorization on the SURLs in the local storage.

 

3.2.1. Parameters

 

                In:           anyURI []                                             arrayOfSURLs,

                                string                                                     authorizationID,

                                TExtraInfo[]                                        storageSystemInfo

 

                Out:       TReturnStatus                                   returnStatus,

TSURLPermissionReturn[]            arrayOfPermissions

 

 

3.2.2. Notes on the Behavior

a)      SRM will check files in its local online and nearline storage.

 

3.2.3. Return Status Code

For request level return status,

SRM_SUCCESS

§  All requests are successfully completed. Permissions on SURLs are checked and returned.

SRM_PARTIAL_SUCCESS

§  All requests are completed. Permissions of some SURLs are successfully checked and returned, but some permission of some SURLs are failed to be checked. Details are on the files status.

SRM_AUTHENTICATION_FAILURE

§  SRM server failed to authenticate the client

SRM_AUTHORIZATION_FAILURE

§  client is not authorized to request permission information

SRM_INVALID_REQUEST

§  arrayOfSURL is empty.

SRM_INTERNAL_ERROR

§  SRM has an internal transient error, and client may try again.

SRM_FAILURE

§  All files requests are failed.

§  any other request failure. Explanation needs to be filled for details.

SRM_NOT_SUPPORTED

§  function is not supported in the SRM server

 

For file level return status,

SRM_SUCCESS

§  successful request completion for the SURL. Permissions on SURL are checked and returned.

SRM_INVALID_PATH

§  SURL does not refer to an existing known path

SRM_AUTHORIZATION_FAILURE

§  client is not authorized to request permission information on the SURL

SRM_FAILURE

§  any other request failure. Explanation needs to be filled for details.

 

3.3. srmGetPermission

               

srmGetPermission is used to get the permissions on the SURLs. It only checks for the client for authorization on the SURLs in the local storage.

 

3.3.1. Parameters

 

                In:           anyURI []                                             arrayOfSURLs,

                                string                                                     authorizationID,

                                TExtraInfo[]                                        storageSystemInfo

 

                Out:       TReturnStatus                                   returnStatus,

TPermissionReturn[]                      arrayOfPermissionReturns

 

 

3.3.2. Notes on the Behavior

b)      SRM will check files in its local online and nearline storage.

 

3.3.3. Return Status Code

For request level return status,

SRM_SUCCESS

§  All requests are successfully completed. Permissions on SURLs are returned.

SRM_PARTIAL_SUCCESS

§  All requests are completed. Permissions of some SURLs are successfully returned, but some permission of some SURLs are failed to be returned. Details are on the files status.

SRM_AUTHENTICATION_FAILURE

§  SRM server failed to authenticate the client

SRM_AUTHORIZATION_FAILURE

§  client is not authorized to request permission information

SRM_INVALID_REQUEST

§  arrayOfSURL is empty.

SRM_INTERNAL_ERROR

§  SRM has an internal transient error, and client may try again.

SRM_FAILURE

§  All files requests are failed.

§  any other request failure. Explanation needs to be filled for details.

SRM_NOT_SUPPORTED

§  function is not supported in the SRM server

 

For file level return status,

SRM_SUCCESS

§  successful request completion for the SURL. Permissions on SURL are returned.

SRM_INVALID_PATH

§  SURL does not refer to an existing known path

SRM_AUTHORIZATION_FAILURE

§  client is not authorized to request permission information on the SURL

SRM_FAILURE

§  any other request failure. Explanation needs to be filled for details.

 

 


4. Directory Functions

 

summary:

srmMkdir

srmRmdir

srmRm

srmLs

srmStatusOfLsRequest

srmMv

 

 

4.1. srmMkdir

 

srmMkdir create a directory in a local SRM space.

 

4.1.1. Parameters

 

                In:           string                                     authorizationID,                              

anyURI                                 SURL,   

                                TExtraInfo[]                        storageSystemInfo

 

Out:       TReturnStatus                   returnStatus

 

4.1.2. Notes on the Behavior

a)      Consistent with unix, recursive creation of directories is not supported.

b)      SURL is a directory path and can include paths, as long as all directory hierarchy exists.

 

4.1.3. Return Status Code

SRM_SUCCESS

§  All requests are successfully completed. SURL is created.

SRM_AUTHENTICATION_FAILURE

§  SRM server failed to authenticate the client

SRM_AUTHORIZATION_FAILURE

§  client is not authorized to create a directory

§  client is not authorized to create a directory as SURL

SRM_INVALID_PATH

§  SURL does not refer to a valid path

§  component of SURL does not refer to an existing path

SRM_DUPLICATION_ERROR

§  SURL exists already

SRM_INTERNAL_ERROR

§  SRM has an internal transient error, and client may try again.

SRM_FAILURE

§  any other request failure. Explanation needs to be filled for details.

SRM_NOT_SUPPORTED

§  function is not supported in the SRM server

 

 

4.2. srmRmdir

 

srmRmdir removes an empty directory in a local SRM space.

 

4.2.1. Parameters

 

                In:           string                                     authorizationID,

anyURI                                 SURL,   

                                TExtraInfo[]                        storageSystemInfo,

                                boolean                               recursive             // false by default

 

Out:       TReturnStatus                   returnStatus

 

4.2.2. Notes on the Behavior

a)      It applies to directory only.

b)      recursive is false by default.

c)       To distinguish from srmRm(), this function is for directories only

d)      When only expired volatile files are in the requested directory, srmRmdir must allow the removal of the requested directory regardless of the expired files. The SURL of the expired volatile files must no longer exist in the file system, and may or may not be removed right away physically depending on the internal server policy.

 

4.2.3. Return Status Code

SRM_SUCCESS

§  All requests are successfully completed. SURL is removed.

SRM_AUTHENTICATION_FAILURE

§  SRM server failed to authenticate the client

SRM_AUTHORIZATION_FAILURE

§  client is not authorized to remove a directory

§  client is not authorized to remove a directory as SURL

SRM_INVALID_PATH

§  SURL does not refer to a valid path

SRM_NON_EMPTY_DIRECTORY

§  SURL is not empty

SRM_INTERNAL_ERROR

§  SRM has an internal transient error, and client may try again.

SRM_FAILURE

§  any other request failure. Explanation needs to be filled for details.

SRM_NOT_SUPPORTED

§  function is not supported in the SRM server

§  input parameter recursive is not supported in the SRM server

 

 

4.3. srmRm

 

This function will remove SURLs (the name space entries) in the storage system. Difference from srmPurgeFromSpace is that srmPurgeFromSpace removes only previously requested “copies” (or “state”) of the SURL in a particular space, and srmPurgeFromSpace shall not remove SURLs or the name space entries.  

 

4.3.1. Parameters

 

                In:           string                                                     authorizationID,

anyURI[]                                              arrayOfSURLs,  

                                TExtraInfo[]                                        storageSystemInfo

 

                Out:       TReturnStatus                                   returnStatus,

TSURLReturnStatus[]                     arrayOfFileStatuses

 

4.3.2. Notes on the Behavior

a)      To distinguish from srmRmdir(), this function applies to files only

b)      srmRm removes all copies or states on the storage, and removes the entry from the name space.

c)       When an SURL is removed, all associated pinned TURLs are all released and removed as well.

d)      srmLs, srmPrepareToGet or srmBringOnline will not find these removed files any more. It must set file requests on SURL from srmPrepareToGet as SRM_ABORTED.

e)      srmRm aborts the SURLs from srmPrepareToPut requests not yet in SRM_PUT_DONE state, and must set its file status as SRM_ABORTED.

f)       srmRm will remove SURLs even if the statuses of the SURLs are SRM_FILE_BUSY. In this case, operations such as srmPrepareToPut or srmCopy that holds the SURL status as SRM_FILE_BUSY must return SRM_INVALID_PATH upon status request or srmPutDone.

 

4.3.3. Return Status Code

For request level return status,

SRM_SUCCESS

§  All requests are successfully completed. All SURLs are removed.

SRM_PARTIAL_SUCCESS

§  All requests are completed. Some SURLs are successfully removed, and some SURLs are failed to be removed. Details are on the files status.

SRM_AUTHENTICATION_FAILURE

§  SRM server failed to authenticate the client

SRM_AUTHORIZATION_FAILURE

§  client is not authorized to remove any files

SRM_INVALID_REQUEST

§  arrayOfSURLs is empty.

SRM_INTERNAL_ERROR

§  SRM has an internal transient error, and client may try again.

SRM_NOT_SUPPORTED

§  function is not supported in the SRM

SRM_FAILURE

§  All files requests are failed.

§  any other request failure. Explanation needs to be filled for details.

 

For file level return status,

SRM_SUCCESS

§  successful request completion for the SURL. SURL is removed.

SRM_INVALID_PATH

§  SURL does not refer to an existing known file path

SRM_AUTHORIZATION_FAILURE

§  client is not authorized to remove SURL

SRM_FILE_LOST

§  the request file is permanently lost.

SRM_FILE_UNAVAILABLE

§  the request file is temporarily unavailable.

SRM_FAILURE

§  any other request failure. Explanation needs to be filled for details.

 

 

4.4. srmLs

 

 srmLs() returns a list of files with a basic information. This operation may be asynchronous, and in such case, requestToken must be returned.

 

4.4.1. Parameters

 

                In:           string                                                     authorizationID,

anyURI []                                             arrayOfSURLs,

TExtraInfo[]                                        storageSystemInfo,

                                TFileStorageType                             fileStorageType,

                                boolean                                               fullDetailedList,

boolean                                               allLevelRecursive,

int                                                           numOfLevels,

int                                                           offset,

int                                                           count

 

                Out:       TReturnStatus                                   returnStatus

                                string                                                     requestToken

TMetaDataPathDetail[]                                 details

 

 

4.4.2. Notes on the Behavior

a)      Applies to both directory and file

b)      fullDetailedList is false by default.

c)       If fullDetailedList is true, the full details are returned.

d)      If allLevelRecursive is true then file lists of all level below current will be provided as well.

e)      If allLevelRecursive is "true" it dominates, i.e. ignore numOfLevels.  If allLevelRecursive is "false" or missing, then do numOfLevels.  If numOfLevels is "0" (zero) or missing, assume a single level.  If both allLevelRecursive and numOfLevels are missing, assume a single level.

f)       Default value of numOfLevels is 1 when not provided.

g)      If numOfLevels is 0, then information about directory itself is returned. Negative value is invalid.

h)      If numOfLevels is 1, then information about files in the directory is returned. Negative value is invalid.

i)        For directory path, appending a slash (/) at the end of the path is recommended.

j)        When listing for a particular type specified by “fileStorageType”, only the files with that type will be in the output.

k)      Empty directories will be returned.

l)        For non-existing or system-prohibited file or directory browsing, SRM_INVALID_PATH must be returned. For non-supported file or directory browsing, SRM_NOT_SUPPORTED must be returned. Explanation needs to be filled for details.

m)    When browsing the top directory is not supported by the SRM, SRM_NOT_SUPPORTED must be returned at the file level.

 

4.4.3. Return Status Code

For request level return status,

SRM_SUCCESS

§  All requests are successfully completed. All SURLs are checked and the information for all SURLs is returned successfully.

SRM_PARTIAL_SUCCESS

§  All requests are completed. Some SURL request is successfully completed, and some SURL request is failed. Details are on the files status.

SRM_REQUEST_QUEUED

§  successful request submission and acceptance. Request token must be returned.

SRM_REQUEST_INPROGRESS

§  Some files are completed, and some files are still on the queue. Details are on the files status.

SRM_AUTHENTICATION_FAILURE

§  SRM server failed to authenticate the client

SRM_AUTHORIZATION_FAILURE

§  client is not authorized to request information

SRM_TOO_MANY_RESULTS

§  srmLs request has generated too many results that SRM cannot handle. In most cases, it needs to be narrowed down with offset and count by the client.

SRM_INTERNAL_ERROR

§  SRM has an internal transient error, and client may try again.

SRM_INVALID_REQUEST

§  Negative values for numOfLevels, offset and count are provided.

§  Operation on the path such as browsing the top directory may be prohibited. Explanation needs to be filled for details.

SRM_NOT_SUPPORTED

§  Requested fileStorageType is not supported in SRM

§  Filtering fileStorageType is not supported in SRM

§  Directory operation (directory SURL, allLevelRecursive and numOfLevels) is not supported in SRM

SRM_FAILURE

§  All files requests are failed.

§  any other request failure. Explanation needs to be filled for details.

 

For file level return status,

SRM_SUCCESS

§  successful request completion for the SURL. The information for the SURL is checked and returned successfully.

SRM_REQUEST_INPROGRESS

§  file request is being served.

SRM_REQUEST_QUEUED

§  file request is still on the queue.

SRM_INVALID_PATH

§  SURL does not refer to an existing known file path.

SRM_AUTHORIZATION_FAILURE

§  client is not authorized to receive the information of the SURL or to access the directory or sub-directories

SRM_FILE_BUSY

§  client requests for files which there is an active srmPrepareToPut (no srmPutDone is not yet called) for.

SRM_FILE_LIFETIME_EXPIRED

§  lifetime on SURL is expired. There is no guarantee of the file still in the cache.

SRM_FILE_IN_CACHE

§  lifetime on SURL has expired, but the file is still in the cache.

SRM_NOT_SUPPORTED

§  Operation on the path such as browsing the top directory may be not supported. Explanation needs to be filled for details.

SRM_FAILURE

§  any other request failure. Explanation needs to be filled for details.

 

 

4.5. srmStatusOfLsRequest

 

srmStatusOfLsRequest() returns a list of files with a basic information. This is an asynchronous operation of srmLs.

 

4.5.1. Parameters

 

                In:           string                                                     authorizationID,

string                                                     requestToken

int                                                           offset,

int                                                           count

 

                Out:       TReturnStatus                                   returnStatus

TMetaDataPathDetail[]                                 details

 

 

4.5.2. Notes on the Behavior

a)      Empty directories will be returned.

b)      For non-existing file or directory, SRM_INVALID_PATH must be returned.

 

4.5.3. Return Status Code

For request level return status,

SRM_SUCCESS

§  All requests are successfully completed. All SURLs are checked and the information for all SURLs is returned successfully.

SRM_PARTIAL_SUCCESS

§  All requests are completed. Some SURL request is successfully completed, and some SURL request is failed. Details are on the files status.

SRM_REQUEST_QUEUED

§  successful request submission and all files request is still on the queue.

SRM_REQUEST_INPROGRESS

§  Some files are completed, and some files are still on the queue. Details are on the files status.

SRM_AUTHENTICATION_FAILURE

§  SRM server failed to authenticate the client

SRM_AUTHORIZATION_FAILURE

§  client is not authorized to request information

SRM_TOO_MANY_RESULTS

§  srmLs request has generated too many results that SRM cannot handle. In most cases, it needs to be narrowed down with offset and count by the client.

SRM_INVALID_REQUEST

§  Negative values for offset and count are provided.

SRM_INTERNAL_ERROR

§  SRM has an internal transient error, and client may try again.

SRM_NOT_SUPPORTED

§  Requested fileStorageType is not supported in SRM

§  Filtering fileStorageType is not supported in SRM

§  Directory operation (directory SURL, allLevelRecursive and numOfLevels) is not supported in SRM

SRM_FAILURE

§  All files requests are failed.

§  any other request failure. Explanation needs to be filled for details.

 

For file level return status,

SRM_SUCCESS

§  successful request completion for the SURL. The information for the SURL is checked and returned successfully.

SRM_REQUEST_INPROGRESS

§  file request is being served.

SRM_REQUEST_QUEUED

§  file request is still on the queue.

SRM_INVALID_PATH

§  SURL does not refer to an existing known file path

SRM_AUTHORIZATION_FAILURE

§  client is not authorized to receive the information of the SURL or to access the directory or sub-directories

SRM_FILE_BUSY

§  client requests for files which there is an active srmPrepareToPut (no srmPutDone is not yet called) for.

SRM_FILE_LIFETIME_EXPIRED

§  lifetime on SURL is expired. There is no guarantee of the file still in the cache.

SRM_FILE_IN_CACHE

§  lifetime on SURL has expired, but the file is still in the cache.

SRM_NOT_SUPPORTED

§  Operation on the path such as browsing the top directory may be not supported. Explanation needs to be filled for details.

SRM_FAILURE

§  any other request failure. Explanation needs to be filled for details.

 

 

 

4.6. srmMv

 

srmMv is to move a file or a directory to destination.

 

4.6.1. Parameters

 

                In:           string                                     authorizationID,

anyURI                                 fromSURL,

                                anyURI                                 toSURL,

                                TExtraInfo[]                        storageSystemInfo

                                 

Out:       TReturnStatus                   returnStatus                     

 

4.6.2. Notes on the Behavior

a)      Applies to both directory and file, and works like unix mv.

b)      Authorization checks need to be performed on both fromSURL and toSURL.

c)       srmMv must fail on SURL that its status is SRM_FILE_BUSY, and SRM_INVALID_REQUEST must be returned.

d)      Moving an SURL to itself results in no operation and SRM_SUCCESS will be returned for no operation.

e)      When moving an SURL to already existing SURL, SRM_DUPLICATION_ERROR must be returned.

 

4.6.3. Return Status Code

SRM_SUCCESS

§  All requests are successfully completed. SURL is moved successfully from one local path to another local path.

SRM_AUTHENTICATION_FAILURE

§  SRM server failed to authenticate the client

SRM_AUTHORIZATION_FAILURE

§  client is not authorized to move fromSURL.

§  Client is not authorized to move a file into toSURL

SRM_INVALID_PATH

§  fromSURL does not refer to an existing known path

§  toSURL does not refer to a valid path

§  status of fromSURL is SRM_FILE_BUSY.

SRM_DUPLICATION_ERROR

§  toSURL exists already.

SRM_FILE_LOST

§  the requested file is permanently lost.

SRM_FILE_BUSY

§  client requests for files which there is an active srmPrepareToPut (no srmPutDone is not yet called) for.

§  The requested file is being used by other clients.

SRM_FILE_UNAVAILABLE

§  the requested file is temporarily unavailable.

SRM_INTERNAL_ERROR

§  SRM has an internal transient error, and client may try again.

SRM_FAILURE

§  any other request failure. Explanation needs to be filled for details.

SRM_NOT_SUPPORTED

§  function is not supported in the SRM server

 


5. Data Transfer Functions

 

summary:

srmPrepareToGet

srmStatusOfGetRequest

srmPrepareToPut

srmStatusOfPutRequest

srmCopy

srmStatusOfCopyRequest

srmBringOnline

srmStatusOfBringOnlineRequest

 

srmReleaseFiles

srmPutDone

 

srmAbortRequest

srmAbortFiles

srmSuspendRequest

srmResumeRequest

 

srmGetRequestSummary

 

srmExtendFileLifeTime

srmGetRequestTokens

 

 

5.1. srmPrepareToGet

 

This function is used to bring files online upon the client’s request and assign TURL so that client can access the file. Lifetime (pinning expiration time) is assigned on the TURL. When specified target space token which must be referred to an online space, the files will be prepared using the space associated with the space token.  It is an asynchronous operation, and request token must be returned if request is valid and accepted. The status must be checked through srmStatusOfGetRequest with the returned request token.

 

5.1.1. Parameters

 

                In:           string                                                     authorizationID,

TGetFileRequest[]                           arrayOfFileRequests,    

                                string                                                     userRequestDescription,             

TExtraInfo[]                                        storageSystemInfo,

                                TFileStorageType                             desiredFileStorageType

                                int                                                           desiredTotalRequestTime

                                int                                                           desiredPinLifetime,

string                                                     targetSpaceToken

TRetentionPolicyInfo                     targetFileRetentionPolicyInfo

TTransferParameters                     transferParameters

 

                Out:       TReturnStatus                                   returnStatus

string                                                     requestToken,

TGetRequestFileStatus[]              arrayOfFileStatuses

                                int                                                           remainingTotalRequestTime

 

5.1.2. Notes on the Behavior

a)      The default value of “lifetime” for Volatile or Durable files will be the lifetime left in the space of the corresponding file type. The default value of “fileStorageType” is Volatile.

b)      If input parameter targetSpaceToken is provided, then the target space token must refer to online space. All requested files will be prepared into the target space.

c)       Input parameter targetFileRetentionPolicyInfo of TRetentionPolicyInfo is to specify the desired retention policy information on the file when the file is prepared online.

d)      If both input parameters targetSpaceToken and TRetentionPolicyInfo are provided, then their types must match exactly. Otherwise, the request may be rejected with SRM_INVALID_REQUEST.

e)      Access latency must be ONLINE always.

f)       Input parameter TAccessPattern is provided at the request-level, and all files will have the same access pattern. 

g)      Optional input parameters in TTransferParameters may collide with the characteristics of the space specified. In this case, TTransferParameters as an input parameter must be ignored.

o)      The userRequestDescription is a user designated name for the request.  It is case-sensitive. SRM server is expected to keep it as client provides. It can be reused by the client. It can be used in the srmGetRequestTokens function to get back the system assigned request tokens.  srmGetRequestTokens will return all the request tokens that have the userRequestDescription.

h)      Only pull mode is supported for file transfers that client must pull the files from the TURL within the expiration time (remainingPinTime).

i)        Input parameter desiredPinLifetime is for a client preferred lifetime (expiration time) on the prepared TURL.

j)        If request is accepted, SRM assigns the requestToken for asynchronous status checking. In such case, the returned status code should be SRM_REQUEST_QUEUED.

k)      totalRequestTime means: All the file transfer for this request must be complete within this totalRequestTime.  Otherwise, SRM_REQUEST_TIMED_OUT must be returned as the request status code with individual file status of SRM_FAILURE with an appropriate explanation.

l)        If desiredTotalRequestTime is unspecified as NULL, the request will be retried for a duration which is dependent on the SRM implementation. 

m)    If input parameter desiredTotalRequestTime is 0 (zero), each file request will be tried at least once.  Negative value is invalid.

n)      Output parameter remainingTotalRequestTime indicates how long the desiredTotalRequestTime is left. If remainingTotalRequestTime is 0 (zero), the request has been timed out. If remainingTotalRequestTime is a negative value (-1), it would mean that each file request will be tried at least once.

o)      The invocation of srmReleaseFile() is expected for finished files later on.

p)      The returned request token should be valid until all files in the request are released or removed.

q)      Streaming mode is allowed. If streaming mode is supported and there is not enough space to hold the request or partially hold the request, the SRM server returns SRM_REQUEST_QUEUED and keeps trying the request for the duration of desiredTotalRequestTime. In the output parameter of explanation in returnStatus, the server may make explicit that the retry is being done. If streaming mode is not supported, the server returns SRM_NO_USER_SPACE or SRM_NO_FREE_SPACE at the file level and SRM_PARTIAL_SUCCESS (if some file requests were successful) or SRM_FAILURE at the request level.

r)       Zero length files must not fail on srmPrepareToGet.

 

5.1.3. Return Status Code

For request level return status,

SRM_REQUEST_QUEUED

§  successful request submission and acceptance. All file requests are on the queue. Request token must be returned.

SRM_REQUEST_INPROGRESS

§  some files are completed, and some files are still on the queue. Request token must be returned.

SRM_SUCCESS

§  all file requests are successfully completed. All SURLs are successfully pinned. For TURLs, file level status needs to be checked.

SRM_PARTIAL_SUCCESS

§  All requests are completed. Some file request is successfully pinned, and some file request is failed. Details are on the files status.

SRM_AUTHENTICATION_FAILURE

§  SRM server failed to authenticate the client

SRM_AUTHORIZATION_FAILURE

§  client is not authorized to submit the request

SRM_INVALID_REQUEST

§  arrayOfFileRequest is empty

§  If both input parameters targetSpaceToken and TRetentionPolicyInfo are provided, then their types must match exactly.

§  Access latency is something other than ONLINE.

§  targetSpaceToken does not refer to an existing known space in the SRM server.

SRM_SPACE_LIFETIME_EXPIRED

§  space associated with the targetSpaceToken is expired.

SRM_EXCEED_ALLOCATION

§  space associated with the targetSpaceToken is not enough to hold all requested SURLs.

SRM_NO_USER_SPACE

§  user space is not enough to hold all requested SURLs.

SRM_NO_FREE_SPACE

§  SRM space is not enough to hold all requested SURLs for free. When client does not specify the targetSpaceToken, SRM uses a default space. The default space is not sufficient to accommodate the request.

SRM_NOT_SUPPORTED

§  SRM server does not support the given input parameters. For example, client requested bbftp for the only transfer protocol, but SRM cannot support that. Client requested desiredFileStorageType that is not supported by the SRM server.

§  targetFileRetentionPolicyInfo does not refer to a supported retention policy in the SRM server.

§  Directory operation is not supported in the SRM server.

§  Recursive directory operation is not supported in the SRM server.

§  None of the file transfer protocols are supported in the SRM server.

SRM_INTERNAL_ERROR

§  SRM has an internal transient error, and client may try again.

SRM_FAILURE

§  All files requests are failed.

§  any other request failure. Explanation needs to be filled for details.

 

For file level return status,

SRM_FILE_PINNED

§  successful request completion for the SURL. SURL is successfully pinned, and TURL is available for access.

SRM_REQUEST_QUEUED

§  file request is on the queue.

SRM_REQUEST_INPROGRESS

§  file request is being served.

SRM_ABORTED

§  The requested file has been aborted.

SRM_RELEASED

§  The requested file has been released.

SRM_FILE_LOST

§  the requested file is permanently lost.

SRM_FILE_BUSY

§  client requests for files which there is an active srmPrepareToPut (no srmPutDone is not yet called) for.

SRM_FILE_UNAVAILABLE

§  the requested file is temporarily unavailable.

SRM_INVALID_PATH

§  SURL does not refer to an existing known file request that is associated with the request token

SRM_AUTHORIZATION_FAILURE

§  client is not authorized to retrieve the file that is associated with the SURL

SRM_FILE_LIFETIME_EXPIRED

§  SURL is expired

§  TURL is expired

§  pin lifetime on TURL has expired, but the file is still in the cache.

SRM_NO_USER_SPACE

§  user space is not enough to hold requested SURL.

SRM_NO_FREE_SPACE

§  SRM space is not enough to hold requested SURL for free. When client does not specify the targetSpaceToken, SRM uses a default space. The default space is not sufficient to accommodate the request.

SRM_FAILURE

§  any other request failure. Explanation needs to be filled for details.

§  The file request would not be able to be completed within the totalRequestTime.

§  The requested file has been suspended because the request has timed out.

 

 

5.2. srmStatusOfGetRequest

 

This function is used to check the status of the previously requested srmPrepareToGet. Request token from srmPrepareToGet must be provided.

 

5.2.1. Parameters

 

                In:           string                                                     requestToken,

                                string                                                     authorizationID

                                anyURI []                                             arrayOfSourceSURLs,

 

                Out:       TReturnStatus                                   returnStatus,

TGetRequestFileStatus[]              arrayOfFileStatuses

                                int                                                           remainingTotalRequestTime

 

5.2.2. Notes on the Behavior

a)      The default value of “lifetime” for Volatile or Durable files will be the lifetime left in the space of the corresponding file type. The default value of “fileStorageType” is Volatile.

b)      If arrayOfSourceSURLs is not provided, SRM must return status for all file requests in the request that is associated with the request token.

c)       When the file is ready and TURL is prepared, the return status code should be SRM_FILE_PINNED.

d)      When the file is ready for the client, the file is implicitly pinned in the cache and lifetime will be enforced, subject to the policies associated with the underlying storage.

e)      If any of the request files is temporarily unavailable, SRM_FILE_UNAVAILABLE must be returned for the file.

f)       If any of the request files is permanently lost, SRM_FILE_LOST must be returned for the file.

g)      The file request must fail with an error SRM_FILE_BUSY if srmPrepareToGet requests for files which there is an active srmPrepareToPut (no srmPutDone is not yet called) for.

h)      SRM must fail (SRM_FAILURE) only if all files in the request failed.

i)        totalRequestTime means: All the file transfer for this request must be complete within this totalRequestTime.  Otherwise, SRM_REQUEST_TIMED_OUT must be returned as the request status code with individual file status of SRM_FAILURE with an appropriate explanation.

j)        Output parameter remainingTotalRequestTime indicates how long the desiredTotalRequestTime is left. If remainingTotalRequestTime is 0 (zero), the request has been timed out. If remainingTotalRequestTime is a negative value (-1), it would mean that each file request will be tried at least once.

k)      Streaming mode is allowed. If streaming mode is supported and there is not enough space to hold the request or partially hold the request, the SRM server returns SRM_REQUEST_QUEUED and keeps trying the request for the duration of desiredTotalRequestTime from the request. remainingTotalRequestTime is being returned. In the output parameter of explanation in returnStatus, the server may make explicit that the retry is being done. If streaming mode is not supported, the server returns SRM_NO_USER_SPACE or SRM_NO_FREE_SPACE at the file level and SRM_PARTIAL_SUCCESS (if some file requests were successful) or SRM_FAILURE at the request level. Clients may need to release files or clean up the target space when target space token was provided.

l)        Output parameter returnStatus must always refer to the request status of the whole request, even if a subset of the whole request was specified in the input for specific file statuses.

 

5.2.3. Return Status Code

For request level return status,

SRM_SUCCESS

§  all file requests are successfully completed. All SURLs are successfully pinned. For TURLs, file level status needs to be checked.

SRM_REQUEST_QUEUED

§  successful request submission and all files request is still on the queue

SRM_REQUEST_INPROGRESS

§  some files are completed, and some files are still on the queue

SRM_PARTIAL_SUCCESS

§  All requests are completed. Some file request is successfully pinned, and some file request is failed. Details are on the files status.

SRM_AUTHENTICATION_FAILURE

§  SRM server failed to authenticate the client

SRM_AUTHORIZATION_FAILURE

§  client is not authorized to submit the request

SRM_INVALID_REQUEST

§  requestToken does not refer to an existing known request in the SRM server.

SRM_SPACE_LIFETIME_EXPIRED

§  space associated with the targetSpaceToken is expired.

SRM_EXCEED_ALLOCATION

§  space associated with the targetSpaceToken is not enough to hold all requested SURLs.

SRM_NO_USER_SPACE

§  user space is not enough to hold all requested SURLs.

SRM_NO_FREE_SPACE

§  SRM space is not enough to hold all requested SURLs for free.

SRM_NOT_SUPPORTED

§  SRM server does not support the given input parameters. For example, client requested bbftp for the only transfer protocol, but SRM cannot support that. Client requested desiredFileStorageType that is not supported by the SRM server.

§  targetFileRetentionPolicyInfo does not refer to a supported retention policy in the SRM server.

§  Directory operation is not supported in the SRM server.

§  Recursive directory operation is not supported in the SRM server.

§  None of the file transfer protocols are supported in the SRM server.

SRM_ABORTED

§  The request has been aborted.

SRM_REQUEST_TIMED_OUT

§  Total request time is over and the rest of the request is failed.

SRM_REQUEST_SUSPENDED

§  request is suspended.

SRM_INTERNAL_ERROR

§  SRM has an internal transient error, and client may try again.

SRM_FAILURE

§  All files requests are failed.

§  any other request failure. Explanation needs to be filled for details.

 

For file level return status,

SRM_FILE_PINNED

§  successful request completion for the SURL. SURL is successfully pinned, and TURL is available for access.

SRM_REQUEST_QUEUED

§  file request is on the queue.

SRM_REQUEST_INPROGRESS

§  file request is being served.

SRM_ABORTED

§  The requested file has been aborted.

SRM_RELEASED

§  The requested file has been released.

SRM_REQUEST_SUSPENDED

§  File request is suspended.

SRM_FILE_LOST

§  the requested file is permanently lost.

SRM_FILE_BUSY

§  client requests for files which there is an active srmPrepareToPut (no srmPutDone is not yet called) for.

SRM_FILE_UNAVAILABLE

§  the requested file is temporarily unavailable.

SRM_INVALID_PATH

§  SURL does not refer to an existing known file request that is associated with the request token

SRM_AUTHORIZATION_FAILURE

§  client is not authorized to retrieve the file that is associated with the SURL

SRM_FILE_LIFETIME_EXPIRED

§  SURL is expired

§  TURL is expired

§  pin lifetime on TURL has expired, but the file is still in the cache

SRM_NO_USER_SPACE

§  user space is not enough to hold requested SURL.

SRM_NO_FREE_SPACE

§  SRM space is not enough to hold requested SURL for free. When client does not specify the targetSpaceToken, SRM uses a default space. The default space is not sufficient to accommodate the request.

SRM_FAILURE

§  any other request failure. Explanation needs to be filled for details.

§  The file request would not be able to be completed within the totalRequestTime.

§  The requested file has been suspended because the request has timed out.

 

 

5.3. srmBringOnline

 

This function is used to bring files online upon the client’s 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. When client specifies target space token which must be referred to an online space, the files will be brought online using the space associated with the space token.  It is an asynchronous operation, and request token must be returned if asynchronous operation is necessary in SRM. The status may be checked through srmStatusOfBringOnlineRequest with the returned request token.

This function is similar to srmPrepareToGet, but it does not return Transfer URL (TURL).

 

5.3.1. Parameters

 

                In:           string                                                                     authorizationID,

TGetFileRequest[]                                           arrayOfFileRequests,    

                                string                                                                     userRequestDescription,             

TExtraInfo[]                                                        storageSystemInfo,

                                TFileStorageType                                             desiredFileStorageType

                                int                                                                           desiredTotalRequestTime

                                int                                                                           desiredLifetime,      // life time on online

string                                                                     targetSpaceToken,

TRetentionPolicyInfo                                     targetFileRetentionPolicyInfo,

TTransferParameters                                     transferParameters,

                                int                                                                           deferredStartTime

 

                Out:       TReturnStatus                                                   returnStatus

string                                                                     requestToken

TBringOnlineRequestFileStatus[]              arrayOfFileStatuses

                                int                                                                           remainingTotalRequestTime

                                int                                                                           remainingDeferredStartTime

               

5.3.2. Notes on the Behavior

a)      Input parameter deferredStartTime is to support CE-SE resource co-allocation and tape mounting efficiency. It means that client does not intent to use the files before that time. If SRM decides not to bring any files until deferredStartTime is reached, SRM_REQUEST_QUEUED must be returned. By default deferredStartTime is 0 (zero) and the request gets queued or processed upon submission. Negative value is invalid.

b)      Output parameter remainingDeferredStartTime indicates how long the deferredStartTime is left, if supported. Negative value is not valid.

c)       Input parameter targetFileRetentionPolicyInfo of TRetentionPolicyInfo is to specify the desired retention policy information on the file when the file is brought online.

d)      If both input parameters targetSpaceToken and TRetentionPolicyInfo are provided, then their types must match exactly. Otherwise, the request may be rejected, and SRM_INVALID_REQUEST will be returned.

e)      Optional input parameters in TTransferParameters may collide with the characteristics of the space specified. In this case, TTransferParameters as an input parameter must be ignored.

f)       If the transfer protocol hints are not specified, default is assumed to be processing mode and LAN access for the site.

g)      Access latency must be ONLINE always.

h)      It is up to the SRM implementation to decide TConnectionType if not provided.

i)        The userRequestDescription is a user designated name for the request. It is case-sensitive. SRM server is expected to keep it as client provides. It can be reused by the client. It can be used in the srmGetRequestTokens function to get back the system assigned request tokens.  srmGetRequestTokens will return all the request tokens that have the userRequestDescription.

j)        Input parameter desiredLifetime is for a client preferred lifetime (expiration time) on the file “copies (or “states”) of the SURLs that will be “brought online” into the target space that is associated with the targetSpaceToken.

k)      This call may be an asynchronous (non-blocking) call, and SRM assigns the requestToken when the request is valid and accepted. The returned status code should be SRM_REQUEST_QUEUED. To get subsequent status and results, separate calls should be made through srmStatusOfBringOnline.

l)        The returned request token should be valid until all files in the request are released, removed or aborted.

m)    totalRequestTime means: All the file transfer for this request must be complete within this desiredTotalRequestTime.  Otherwise, SRM_REQUEST_TIMED_OUT must be returned as the request status code with individual file status of SRM_FAILURE with an appropriate explanation.

n)      If input parameter desiredTotalRequestTime is unspecified as NULL, the request will be retried for a duration which is dependent on the SRM implementation. 

o)      If input parameter desiredTotalRequestTime is 0 (zero), each file request will be tried at least once.  Negative value is not valid.

p)      Output parameter remainingTotalRequestTime indicates how long the desiredTotalRequestTime is left. If remainingTotalRequestTime is 0 (zero), the request has been timed out. If remainingTotalRequestTime is a negative value (-1), it would mean that each file request will be tried at least once.

q)      When srmAbortRequest is requested for srmBringOnline request, the request gets aborted, but those files that are brought online will remain in the space where they are brought in, and are not removed.  Clients need to remove those files through srmPurgeFromSpace or srmRm.

r)       Streaming mode is allowed. If streaming mode is supported and there is not enough space to hold the request or partially hold the request, the SRM server returns SRM_REQUEST_QUEUED and keeps trying the request for the duration of desiredTotalRequestTime from the request. In the output parameter of explanation in returnStatus, the server may make explicit that the retry is being done. If streaming mode is not supported, the server returns SRM_NO_USER_SPACE or SRM_NO_FREE_SPACE at the file level and SRM_PARTIAL_SUCCESS (if some file requests were successful) or SRM_FAILURE at the request level.

 

5.3.3. Return Status Code

For request level return status,

SRM_REQUEST_QUEUED

§  successful request submission and acceptance. All file requests are on the queue. Request token must be returned.

SRM_REQUEST_INPROGRESS

§  some files are completed, and some files are not completed yet. Request token must be returned.

SRM_SUCCESS

§  All requests are successfully completed. All SURLs are successfully brought online.

SRM_PARTIAL_SUCCESS

§  All requests are completed. Some files are successfully brought online, and some files are failed. Details are on the files status.

SRM_AUTHENTICATION_FAILURE

§  SRM server failed to authenticate the client

SRM_AUTHORIZATION_FAILURE

§  client is not authorized to submit the request

SRM_INVALID_REQUEST

§  arrayOfFileRequest is empty

§  Access latency refers to something other than ONLINE.

§  If both input parameters targetSpaceToken and TRetentionPolicyInfo are provided, then their types must match exactly.

§  targetSpaceToken does not refer to an existing known space in the SRM server.

§  deferredStartTime is negative.

SRM_SPACE_LIFETIME_EXPIRED

§  space associated with the targetSpaceToken is expired.

SRM_EXCEED_ALLOCATION

§  space associated with the targetSpaceToken is not enough to hold all requested SURLs.

SRM_NO_USER_SPACE

§  user space is not enough to hold all requested SURLs.

SRM_NO_FREE_SPACE

§  SRM space is not enough to hold all requested SURLs for free.

SRM_INTERNAL_ERROR

§  SRM has an internal transient error, and client may try again.

SRM_NOT_SUPPORTED

§  SRM server does not support the given input parameters. For example, client requested bbftp for the only transfer protocol, but SRM cannot support that. Client requested desiredFileStorageType that is not supported by the SRM server.

§  targetFileRetentionPolicyInfo does not refer to a supported retention policy in the SRM server.

§  deferredStartTime is not supported in the SRM server.

§  Directory operation is not supported in the SRM server.

§  Recursive directory operation is not supported in the SRM server.

§  None of the file transfer protocols are supported in the SRM server.

SRM_FAILURE

§  All files requests are failed.

§  any other request failure. Explanation needs to be filled for details.

 

For file level return status,

SRM_SUCCESS

§  successful request completion for the SURL. SURL is successfully brought online.

SRM_REQUEST_QUEUED

§  file request is on the queue.

SRM_REQUEST_INPROGRESS

§  file request is being served.

SRM_AUTHORIZATION_FAILURE

§  client is not authorized to retrieve the file that is associated with the SURL

SRM_ABORTED

§  The requested file has been aborted.

SRM_RELEASED

§  The requested file has been released.

SRM_FILE_LOST

§  the requested file is permanently lost.

SRM_FILE_BUSY

§  client requests for files which there is an active srmPrepareToPut (no srmPutDone is not yet called) for.

SRM_FILE_UNAVAILABLE

§  the requested file is temporarily unavailable.

SRM_INVALID_PATH

§  SURL does not refer to an existing known file request that is associated with the request token

SRM_FILE_LIFETIME_EXPIRED

§  SURL is expired

§  pin lifetime has expired, but the file is still in the cache

SRM_NO_USER_SPACE

§  user space is not enough to hold requested SURL.

SRM_NO_FREE_SPACE

§  SRM space is not enough to hold requested SURL for free. When client does not specify the targetSpaceToken, SRM uses a default space. The default space is not sufficient to accommodate the request.

SRM_FAILURE

§  any other request failure. Explanation needs to be filled for details.

§  The file request would not be able to be completed within the totalRequestTime.

§  The requested file has been suspended because the request has timed out.

 

 

5.4. srmStatusOfBringOnlineRequest

 

This function is used to check the status of the previous request to srmBringOnline, when asynchronous operation is necessary in the SRM. Request token must have been provided in response to the srmBringOnline.

 

5.4.1. Parameters

 

                In:           string                                                                     requestToken,

                                string                                                                     authorizationID

                                anyURI []                                                             arrayOfSourceSURLs,

 

                Out:       TReturnStatus                                                   returnStatus,

TBringOnlineRequestFileStatus[]              arrayOfFileStatuses

                                int                                                                           remainingTotalRequestTime

                                int                                                                           remainingDeferredStartTime

 

5.4.2. Notes on the Behavior

a)      If arrayOfSourceSURLs is not provided, returns status for all files in this request.

b)      When the file is ready online, the return status code should be SRM_FILE_IN_CACHE.

c)       Output parameter remainingDeferredStartTime indicates how long the deferredStartTime is left, if supported. Negative value is not valid.

d)      When the file is ready for the client, the file is implicitly pinned in the cache and lifetime will be enforced, subject to the policies associated with the underlying storage.

e)      If any of the request files is temporarily unavailable, SRM_FILE_UNAVAILABLE must be returned for the file.

f)       If any of the request files is permanently lost, SRM_FILE_LOST must be returned for the file.

g)      The file request must fail with an error SRM_FILE_BUSY if srmBringOnline requests for files which there is an active srmPrepareToPut (no srmPutDone is not yet called) for.

h)      SRM must fail (SRM_FAILURE) only if all files in the request failed.

i)        totalRequestTime means: All the file transfer for this request must be complete within this totalRequestTime.  Otherwise, SRM_REQUEST_TIMED_OUT must be returned as the request status code with individual file status of SRM_FAILURE with an appropriate explanation.

j)        Output parameter remainingTotalRequestTime indicates how long the desiredTotalRequestTime is left. If remainingTotalRequestTime is 0 (zero), the request has been timed out. If remainingTotalRequestTime is a negative value (-1), it would mean that each file request will be tried at least once.

k)      If SRM decides not to bring any files until input parameter deferredStartTime is reached, SRM_REQUEST_QUEUED must be returned.

l)        Streaming mode is allowed. If streaming mode is supported and there is not enough space to hold the request or partially hold the request, the SRM server returns SRM_REQUEST_QUEUED and keeps trying the request for the duration of desiredTotalRequestTime from the request. remainingTotalRequestTime is being returned. In the output parameter of explanation in returnStatus, the server may make explicit that the retry is being done. If streaming mode is not supported, the server returns SRM_NO_USER_SPACE or SRM_NO_FREE_SPACE at the file level and SRM_PARTIAL_SUCCESS (if some file requests were successful) or SRM_FAILURE at the request level. Clients may need to release files or clean up the target space when target space token was provided.

m)    Output parameter returnStatus must always refer to the request status of the whole request, even if a subset of the whole request was specified in the input for specific file statuses.

 

5.4.3. Return Status Code

For request level return status,

SRM_SUCCESS

§  All requests are successfully completed. All SURLs are successfully brought online.

SRM_REQUEST_QUEUED

§  successful request submission and all files request is on the queue

SRM_REQUEST_INPROGRESS

§  some files are completed, and some files are not completed yet.

SRM_PARTIAL_SUCCESS

§  All requests are completed. Some files are successfully brought online, and some files are failed. Details are on the files status.

SRM_AUTHENTICATION_FAILURE

§  SRM server failed to authenticate the client

SRM_AUTHORIZATION_FAILURE

§  client is not authorized to submit the request

SRM_INVALID_REQUEST

§  requestToken does not refer to an existing known request in the SRM server.

SRM_NOT_SUPPORTED

§  SRM server does not support the given input parameters. For example, client requested bbftp for the only transfer protocol, but SRM cannot support that. Client requested desiredFileStorageType that is not supported by the SRM server.

§  targetFileRetentionPolicyInfo does not refer to a supported retention policy in the SRM server.

§  deferredStartTime is not supported in the SRM server.

§  Directory operation is not supported in the SRM server.

§  Recursive directory operation is not supported in the SRM server.

§  None of the file transfer protocols are supported in the SRM server.

SRM_SPACE_LIFETIME_EXPIRED

§  space associated with the targetSpaceToken is expired.

SRM_EXCEED_ALLOCATION

§  space associated with the targetSpaceToken is not enough to hold all requested SURLs.

SRM_NO_USER_SPACE

§  user space is not enough to hold all requested SURLs.

SRM_NO_FREE_SPACE

§  SRM space is not enough to hold all requested SURLs for free.

SRM_ABORTED

§  The request has been aborted.

SRM_REQUEST_TIMED_OUT

§  Total request time is over and the rest of the request is failed.

SRM_REQUEST_SUSPENDED

§  request is suspended.

SRM_INTERNAL_ERROR

§  SRM has an internal transient error, and client may try again.

SRM_FAILURE

§  All files requests are failed.

§  any other request failure. Explanation needs to be filled for details.

 

For file level return status,

SRM_SUCCESS

§  successful request completion for the SURL. SURL is successfully brought online.

SRM_REQUEST_QUEUED

§  file request is on the queue.

SRM_REQUEST_INPROGRESS

§  file request is being served.

SRM_AUTHORIZATION_FAILURE

§  client is not authorized to retrieve the file that is associated with the SURL

SRM_ABORTED

§  The requested file has been aborted.

SRM_RELEASED

§  The requested file has been released.

SRM_REQUEST_SUSPENDED

§  File request is suspended.

SRM_FILE_LOST

§  the requested file is permanently lost.

SRM_FILE_BUSY

§  client requests for files which there is an active srmPrepareToPut (no srmPutDone is not yet called) for.

SRM_FILE_UNAVAILABLE

§  the requested file is temporarily unavailable.

SRM_INVALID_PATH

§  SURL does not refer to an existing known file request that is associated with the request token

SRM_FILE_LIFETIME_EXPIRED

§  SURL is expired

§  pin lifetime has expired, but the file is still in the cache

SRM_NO_USER_SPACE

§  user space is not enough to hold requested SURL.

SRM_NO_FREE_SPACE

§  SRM space is not enough to hold requested SURL for free. When client does not specify the targetSpaceToken, SRM uses a default space. The default space is not sufficient to accommodate the request.

SRM_FAILURE

§  any other request failure. Explanation needs to be filled for details.

§  The file request would not be able to be completed within the totalRequestTime.

§  The requested file has been suspended because the request has timed out.

 

 

5.5. srmPrepareToPut

 

This function is used to write files into the storage. Upon the client’s request, SRM prepares a TURL so that client can write data into the TURL. Lifetime (pinning expiration time) is assigned on the TURL. When a specified target space token is provided, the files will be located finally in the targeted space associated with the target space token.  It is an asynchronous operation, and request token must be returned if the request is valid and accepted to the SRM. The status may be checked through srmStatusOfPutRequest with the returned request token.

 

5.5.1. Parameters

 

                In:           string                                                     authorizationID,

TPutFileRequest[]                           arrayOfFileRequests,    

string                                                     userRequestDescription,

                                TOverwriteMode                             overwriteOption,

                                TExtraInfo[]                                        storageSystemInfo,

                                int                                                           desiredTotalRequestTime

                                int                                                           desiredPinLifetime,   // on TURL

                                int                                                           desiredFileLifetime,   // on SURL

                                TFileStorageType                             desiredFileStorageType,

string                                                     targetSpaceToken

TRetentionPolicyInfo                     targetFileRetentionPolicyInfo

TTransferParameters                     transferParameters

 

                Out:       TReturnStatus                                   returnStatus

string                                                     requestToken,

TPutRequestFileStatus[]                               arrayOfFileStatuses

                                int                                                           remainingTotalRequestTime

 

 

5.5.2. Notes on the Behavior

a)      The default value of “lifetime” for Volatile or Durable files will be the lifetime left in the space of the corresponding file type. The default value of “fileStorageType” is Volatile.

b)      TURL returned by the srmPrepareToPut may not be used for read access with any protocol. An explicit srmPrepareToGet or srmBringOnline is required.

c)       Optional input parameters in TTransferParameters may collide with the characteristics of the space specified. In this case, TTransferParameters as an input parameter must be ignored.

d)      Input parameter userRequestDescription may be null, and it is case-sensitive when provided. SRM server is expected to keep it as client provides. It can be reused by the client. It can be used in the srmGetRequestTokens function to get back the system assigned request tokens.  srmGetRequestTokens will return all the request tokens that have the userRequestDescription.

e)      Input parameter targetSpaceToken is provided at the request-level, and all files in the request will end up in the space that is associated with the target space token if the space is enough for all files.

f)       Input parameter targetFileRetentionPolicyInfo of TRetentionPolicyInfo is to specify the desired retention policy information on the file when the file is written into the target storage system.

g)      If both input parameters targetSpaceToken and TRetentionPolicyInfo are provided, then their types must match exactly. Otherwise, the request may be rejected and SRM_INVALID_REQUEST must be returned.

h)      Only push mode is supported for file transfers that client must “push” the file to the prepared TURL.

i)        Input parameter targetSURL in the TPutFileRequest has to be local to SRM. If targetSURL is not specified, SRM will generate a reference SURL for the file request automatically and put it in the specified user space if provided. This reference SURL will be returned along with the “Transfer URL”.  Some SRM implementation may require targetSURL.

j)        srmPutDone() is expected after each file is “put” into the prepared TURL.

k)      Input parameter desiredPinLifetime is the lifetime (expiration time) on the TURL when the Transfer URL is prepared. It does not refer to the lifetime of the SURL. TURLs will not be valid any more after the desiredPinLifetime is over if srmPutDone or srmAbortRequest is not submitted on the SURL before expiration. In such case, the server returns SRM_FAILURE at the file level.

l)        Input parameter desiredFileLifetime is the lifetime of the SURL when the file is put into the storage system. It does not refer to the lifetime (expiration time) of the TURL. Lifetime on SURL starts when successrul srmPutDone is executed.

m)    The lifetime of the SURL starts as soon as SRM receives the srmPutDone().  If srmPutDone() is not provided, then the files in that space are subject to removal when the lifetime on the TURL expires or the lifetime on the space expires.  The lifetime on the TURL can be found in the status of the file request as output parameter remainingPinTime in TPutRequestFileStatus.

n)      If request is accepted, SRM assigns the requestToken for asynchronous status checking. In such case, the returned status code should be SRM_REQUEST_QUEUED.

o)      totalRequestTime means: All the file transfer for this request must be complete within this totalRequestTime.  Otherwise, SRM_REQUEST_TIMED_OUT must be returned as the request status code with individual file status of SRM_FAILURE with an appropriate explanation.

p)      If input parameter desiredTotalRequestTime is unspecified as NULL, the request will be retried for a duration which is dependent on the SRM implementation. 

q)      If input parameter desiredTotalRequestTime is 0 (zero), each file request will be tried at least once.  Negative value is invalid.

r)       Output parameter remainingTotalRequestTime indicates how long the desiredTotalRequestTime is left. If remainingTotalRequestTime is 0 (zero), the request has been timed out. If remainingTotalRequestTime is a negative value (-1), it would mean that each file request will be tried at least once.

s)       Streaming mode is allowed. If streaming mode is supported and there is not enough space to hold the request or partially hold the request, the SRM server returns SRM_REQUEST_QUEUED and keeps trying the request for the duration of desiredTotalRequestTime from the request. In the output parameter of explanation in returnStatus, the server may make explicit that the retry is being done. If streaming mode is not supported, the server returns SRM_NO_USER_SPACE or SRM_NO_FREE_SPACE at the file level and SRM_PARTIAL_SUCCESS (if some file requests were successful) or SRM_FAILURE at the request level.

t)       Upon srmPrepareToPut, SURL entry is inserted to the name space, and any methods that access the SURL such as srmLs, srmBringOnline and srmPrepareToGet must return SRM_FILE_BUSY at the file level. If another srmPrepareToPut or srmCopy were requested on the same SURL, SRM_FILE_BUSY must be returned if the SURL can be overwritten, otherwise SRM_DUPLICATION_ERROR must be returned at the file level.

u)      Input parameter overwriteOption is assumed to be NEVER when not specified.

v)      When requested file storage type is VOLATILE, it cannot be promoted to PERMANENT to avoid complexities in space accounting and other cleanup tasks. SRM_NOT_SUPPORTED must be returned if the requested file storage type is not supported, or the request must be processed.

w)    After TURL is returned, srmMv operation on the corresponding SURL may be requested. srmPutDone on the original SURL will succeed, and SRM_SUCCESS must be returned at the file level upon successful srmPutDone.

x)      Zero length files must not fail on srmPrepareToPut.

y)      When a VOLATILE file is put into an unreserved replica quality space without any space token being used, and the VOLATILE file gets expired, SRM must remove its SURL from the file system. The file may or may not be removed physically right away.

 

5.5.3. Return Status Code

For request level return status,

SRM_REQUEST_QUEUED

§  successful request submission and acceptance. All file requests are on the queue. Request token must be returned.

SRM_REQUEST_INPROGRESS

§  some files are completed, and some files are still on the queue. Request token must be returned.

SRM_SUCCESS

§  All requests are successfully completed. For all SURLs, spaces are allocated, and TURLs are prepared.

SRM_PARTIAL_SUCCESS

§  All requests are completed. For some file requests, the spaces are allocated and TURLs are prepared, but for some file requests, it is failed. Details are on the files status.

SRM_AUTHENTICATION_FAILURE

§  SRM server failed to authenticate the client

SRM_AUTHORIZATION_FAILURE

§  client is not authorized to submit the request

SRM_INVALID_REQUEST

§  If both input parameters targetSpaceToken and TRetentionPolicyInfo are provided, then their types must match exactly.

§  targetSpaceToken does not refer to an existing known space in the SRM server.

SRM_SPACE_LIFETIME_EXPIRED

§  space associated with the targetSpaceToken is expired.

SRM_EXCEED_ALLOCATION

§  space associated with the targetSpaceToken is not enough to hold all requested SURLs.

SRM_NO_USER_SPACE

§  user space is not enough to hold all requested SURLs.

SRM_NO_FREE_SPACE

§  SRM space is not enough to hold all requested SURLs for free.

SRM_INTERNAL_ERROR

§  SRM has an internal transient error, and client may try again.

SRM_NOT_SUPPORTED

§  SRM server does not support the given input parameters. For example, client requested bbftp for the only transfer protocol, but SRM cannot support that. Client requested desiredFileStorageType that is not supported by the SRM server.

§  targetFileRetentionPolicyInfo does not refer to a supported retention policy in the SRM server.

§  None of the file transfer protocols are supported in the SRM server.

SRM_FAILURE

§  All files requests are failed.

§  any other request failure. Explanation needs to be filled for details.

 

For file level return status,

SRM_SPACE_AVAILABLE

§  successful request completion for the “put” request. The space is allocated, and TURL is prepared.

SRM_REQUEST_QUEUED

§  file request is on the queue.

SRM_REQUEST_INPROGRESS

§  file request is being served.

SRM_FILE_IN_CACHE

§  lifetime on SURL has expired, but the file is still in the cache.

SRM_INVALID_PATH

§  targetSURL does not refer to a valid path.

SRM_DUPLICATION_ERROR

§  targetSURL refers to an existing SURL and overwriting is not allowed.

SRM_FILE_BUSY

§  client requests for files which there is an active srmPrepareToPut (no srmPutDone is not yet called) or srmCopy for.

SRM_AUTHORIZATION_FAILURE

§  client is not authorized to retrieve the file that is associated with the SURL

SRM_ABORTED

§  The requested file has been aborted.

SRM_NO_USER_SPACE

§  user space is not enough to hold the requested SURL.

SRM_NO_FREE_SPACE

§  SRM space is not enough to hold the requested SURL for free.

SRM_FAILURE

§  any other request failure. Explanation needs to be filled for details.

§  The file request would not be able to be completed within the totalRequestTime.

§  The requested file has been suspended because the request has timed out.

§  The file request is not aborted or completed by srmPutDone, and the TURL (available space allocation for the file) is not valid any more.

 

 

5.6. srmStatusOfPutRequest

 

This function is used to check the status of the previously requested srmPrepareToPut. Request token from srmPrepareToPut must be provided.

 

5.6.1. Parameters

 

                In:           string                                                     requestToken,

                                string                                                     authorizationID

                                anyURI []                                             arrayOfTargetSURLs,

 

                Out:       TReturnStatus                                   returnStatus,

TPutRequestFileStatus[]                               arrayOfFileStatuses

                                int                                                           remainingTotalRequestTime

 

5.6.2. Notes on the Behavior

a)      The default value of “lifetime” for Volatile or Durable files will be the lifetime left in the space of the corresponding file type. The default value of “fileStorageType” is Volatile.

b)      If arrayOfTargetSURLs is not provided, returns status for all the file requests in this request.

c)       When the space is ready for client to “put” data and TURL is prepared, the return status code should be SRM_SPACE_AVAILABLE.

d)      When the file space is ready for the client, the TURL is available in the cache and pin lifetime on the TURL will be enforced. TURLs will not be valid any more after the pin lifetime is over if srmPutDone or srmAbortRequest is not submitted on the SURL before expiration. In such case, the server returns SRM_FAILURE at the file level.

e)      If a targetSURL is provided with some directory structure, the directory structure must exist, and SRM will not create the directory structure for the targetSURL.  In such case, SRM_INVALID_PATH must be returned. srmMkdir may be used to create the directory structure.

f)       Lifetime on SURL starts when successrul srmPutDone is executed.

g)      If the space for the requested files is full, and TURL cannot be returned, then SRM_EXCEED_ALLOCATION, SRM_NO_USER_SPACE, or SRM_NO_FREE_SPACE must be returned for the files.

h)      SRM must fail (SRM_FAILURE) only if all files in the request failed.

i)        totalRequestTime means: All the file transfer for this request must be complete within this totalRequestTime.  Otherwise, SRM_REQUEST_TIMED_OUT must be returned as the request status code with individual file status of SRM_FAILURE with an appropriate explanation.

j)        Output parameter remainingTotalRequestTime indicates how long the desiredTotalRequestTime is left. If remainingTotalRequestTime is 0 (zero), the request has been timed out. If remainingTotalRequestTime is a negative value (-1), it would mean that each file request will be tried at least once.

k)      Streaming mode is allowed. If streaming mode is supported and there is not enough space to hold the request or partially hold the request, the SRM server returns SRM_REQUEST_QUEUED and keeps trying the request for the duration of desiredTotalRequestTime from the request. remainingTotalRequestTime is being returned. In the output parameter of explanation in returnStatus, the server may make explicit that the retry is being done. If streaming mode is not supported, the server returns SRM_NO_USER_SPACE or SRM_NO_FREE_SPACE at the file level and SRM_PARTIAL_SUCCESS (if some file requests were successful) or SRM_FAILURE at the request level. Clients may need to clean up the target space when target space token was provided.

l)        Upon srmPrepareToPut, SURL entry is inserted to the name space, and any methods that access the SURL such as srmLs, srmBringOnline and srmPrepareToGet must return SRM_FILE_BUSY at the file level. If another srmPrepareToPut or srmCopy were requested on the same SURL, SRM_FILE_BUSY must be returned if the SURL can be overwritten, otherwise SRM_DUPLICATION_ERROR must be returned at the file level.

m)    srmRm may remove SURLs even if the statuses of the SURLs are SRM_FILE_BUSY. In this case, the status for srmPrepareToPut request must return SRM_INVALID_PATH upon status request or srmPutDone.

n)      After TURL is returned, srmMv operation on the corresponding SURL may be requested. srmPutDone on the original SURL will succeed, and SRM_SUCCESS must be returned at the file level upon successful srmPutDone.

o)      Output parameter returnStatus must always refer to the request status of the whole request, even if a subset of the whole request was specified in the input for specific file statuses.

 

5.6.3. Return Status Code

For request level return status,

SRM_SUCCESS

§  All requests are successfully completed. For all SURLs, spaces are allocated, and TURLs are prepared.

SRM_REQUEST_QUEUED

§  successful request submission and all files request is still on the queue

SRM_REQUEST_INPROGRESS

§  some files are completed, and some files are still on the queue

SRM_PARTIAL_SUCCESS

§  All requests are completed. For some file requests, the spaces are allocated and TURLs are prepared, but for some file requests, it is failed. Details are on the files status.

SRM_AUTHENTICATION_FAILURE

§  SRM server failed to authenticate the client

SRM_AUTHORIZATION_FAILURE

§  client is not authorized to submit the request

SRM_INVALID_REQUEST

§  requestToken does not refer to an existing known request in the SRM server.

§  targetSpaceToken that client provided does not refer to an existing space in the SRM server.

SRM_SPACE_LIFETIME_EXPIRED

§  space associated with the targetSpaceToken is expired.

SRM_EXCEED_ALLOCATION

§  space associated with the targetSpaceToken is not enough to hold all requested SURLs.

SRM_NO_USER_SPACE

§  user space is not enough to hold all requested SURLs.

SRM_NO_FREE_SPACE

§  SRM space is not enough to hold all requested SURLs for free.

SRM_REQUEST_TIMED_OUT

§  Total request time is over and the rest of the request is failed.

SRM_ABORTED

§  The request has been aborted.

SRM_REQUEST_SUSPENDED

§  The request is suspended.

SRM_INTERNAL_ERROR

§  SRM has an internal transient error, and client may try again.

SRM_NOT_SUPPORTED

§  SRM server does not support the given input parameters. For example, client requested bbftp for the only transfer protocol, but SRM cannot support that. Client requested desiredFileStorageType that is not supported by the SRM server.

§  targetFileRetentionPolicyInfo does not refer to a supported retention policy in the SRM server.

§  None of the file transfer protocols are supported in the SRM server.

SRM_FAILURE

§  All files requests are failed.

§  any other request failure. Explanation needs to be filled for details.

 

For file level return status,

SRM_SPACE_AVAILABLE

§  successful request completion for the “put” request. The space is allocated, and TURL is prepared.

SRM_REQUEST_QUEUED

§  file request is on the queue.

SRM_REQUEST_INPROGRESS

§  file request is being served.

SRM_SUCCESS

§  Client’s file transfer into TURL is completed, and srmPutDone on the targetSURL is completed. The file is now in the cache and lifetime on the targetSURL is started.

SRM_FILE_IN_CACHE

§  lifetime on SURL has expired, but the file is still in the cache.

SRM_INVALID_PATH

§  targetSURL does not refer to a valid path.

SRM_DUPLICATION_ERROR

§  targetSURL refers to an existing SURL and overwriting is not allowed.

SRM_FILE_BUSY

§  client requests for files which there is an active srmPrepareToPut (no srmPutDone is not yet called) or srmCopy for.

SRM_AUTHORIZATION_FAILURE

§  client is not authorized to retrieve the file that is associated with the SURL

SRM_ABORTED

§  The requested file has been aborted.

SRM_REQUEST_SUSPENDED

§  File request is suspended.

SRM_NO_USER_SPACE

§  user space is not enough to hold the requested SURL.

SRM_NO_FREE_SPACE

§  SRM space is not enough to hold the requested SURL for free.

SRM_FAILURE

§  any other request failure. Explanation needs to be filled for details.

§  The file request would not be able to be completed within the totalRequestTime.

§  The requested file has been suspended because the request has timed out.

§  The file request is not aborted or completed by srmPutDone, and the TURL (available space allocation for the file) is not valid any more.

 

 

5.7. srmCopy

 

This function is used to copy files from source storage sites into the target storage sites. The source storage site or the target storage site needs to be the SRM itself that the client makes the srmCopy request. If both source and target are local to the SRM, it performed a local copy. There are two cases for remote copies: 1. Target SRM is where client makes a srmCopy request (PULL case), 2. Source SRM is where client makes a srmCopy request (PUSH case). 

  1. PULL case: Upon the client’s srmCopy request, the target SRM makes a space at the target storage, and makes a request srmPrepareToGet to the source SRM. When TURL is ready at the source SRM, the target SR M transfers the file from the source TURL into the prepared target storage. After the file transfer completes, srmReleaseFiles is issued to the source SRM.
  2. PUSH case: Upon the client’s srmCopy request, the source SRM prepares a file to be transferred out to the target SRM, and makes a request srmPrepareToPut to the target SRM. When TURL is ready at the target SRM, the source SRM transfers the file from the prepared source into the prepared target TURL. After the file transfer completes, srmPutDone is issued to the target SRM.

When specified target space token is provided, the files will be located finally in the targeted space associated with the space token.  It is an asynchronous operation, and request token must be returned. The status may be checked through srmStatusOfCopyRequest with the returned request token.

 

5.7.1. Parameters

 

                In:           string                                                     authorizationID,

TCopyFileRequest[]                        arrayOfFileRequests,                    

                                string                                                     userRequestDescription,

                                TOverwriteMode                             overwriteOption,

                                int                                                           desiredTotalRequestTime,

                                int                                                           desiredTargetSURLLifeTime,      

                                TFileStorageType                             targetFileStorageType,

string                                                     targetSpaceToken,

TRetentionPolicyInfo                     targetFileRetentionPolicyInfo,

                                TExtraInfo[]                                        sourceStorageSystemInfo,

                                TExtraInfo[]                                        targetStorageSystemInfo

 

                Out:       TReturnStatus                                   returnStatus,

string                                                     requestToken,

TCopyRequestFileStatus[]           arrayOfFileStatuses,

                                int                                                           remainingTotalRequestTime

 

 

5.7.2. Notes on the Behavior

a)      The default value of “lifetime” for Volatile or Durable files will be the lifetime left in the space of the corresponding file type. The default value of “fileType” is Volatile.

b)      When aborted, target SURLs need to be provided.

c)       Input parameter userRequestDescription may be null, and it is case-sensitive when provided. SRM server is expected to keep it as client provides. It can be reused by the client. It can be used in the srmGetRequestTokens function to get back the system assigned request tokens.  srmGetRequestTokens will return all the request tokens that have the userRequestDescription.

d)      Input parameter targetSpaceToken is provided at the request-level, and all files in the request will end up in the space that is associated with the target space token.

e)      Input parameter targetFileRetentionPolicyInfo of TRetentionPolicyInfo is to specify the desired retention policy information on the file when the file is written into the target storage system.

f)       If both input parameters targetSpaceToken and TRetentionPolicyInfo are provided, then their types must match exactly. Otherwise, the request may be rejected, and SRM_INVALID_REQUEST must be returned.

g)      If request is accepted, SRM assigns the requestToken for asynchronous status checking. In such case, the returned status code should be SRM_REQUEST_QUEUED.

h)      Pull mode: copy from remote location to the SRM. (e.g. from remote to MSS.)

i)        Push mode: copy from the SRM to remote location.

j)        Always release files through srmReleaseFiles from the source after copy is done, if source is an SRM and PULL mode was performed.

k)      Always issue srmPutDone to the target after copy is done, if target is an SRM and PUSH mode was performed.

l)        Note there is no protocol negotiation with the client for this request.

m)    totalRequestTime means: if all the file transfer for this request must be complete in this totalRequestTime. Otherwise, the request is returned as failed at the end of the totalRequestTime, and SRM_REQUEST_TIMED_OUT must be returned as the request status code with individual file status of SRM_FAILURE with an appropriate explanation. All completed files must not be removed, but status of the files must be returned to the client.

n)      If input parameter desiredTotalRequestTime is unspecified as NULL, the request will be retried for a duration which is dependent on the SRM implementation. 

o)      If input parameter desiredTotalRequestTime is 0 (zero), each file request will be tried at least once.  Negative value is invalid.

p)      Output parameter remainingTotalRequestTime indicates how long the desiredTotalRequestTime is left. If remainingTotalRequestTime is 0 (zero), the request has been timed out. If remainingTotalRequestTime is a negative value (-1), it would mean that each file request will be tried at least once.

q)      When both sourceSURL and targetSURL are local, local copy must be performed.

r)       Empty directories are copied as well.

s)       If a targetSURL is provided with some directory structure, the directory structure must exist, and SRM will not create the directory structure for the targetSURL.  In such case, SRM_INVALID_PATH must be returned. srmMkdir may be used to create the directory structure.

t)       If the sourceSURL and targetSURL are provided as directories (copying directories) when SRM implementation supports, then all sub directories will be copied over from the source to the target, and complete sub-directory structure will be created only if TDirOption indicates them.

u)      Streaming mode is allowed. If streaming mode is supported and there is not enough space to hold the request or partially hold the request, the SRM server returns SRM_REQUEST_QUEUED and keeps trying the request for the duration of desiredTotalRequestTime from the request. In the output parameter of explanation in returnStatus, the server may make explicit that the retry is being done. If streaming mode is not supported, the server returns SRM_NO_USER_SPACE or SRM_NO_FREE_SPACE at the file level and SRM_PARTIAL_SUCCESS (if some file requests were successful) or SRM_FAILURE at the request level. Clients may need to clean up the target space when target space token was provided.

v)      Upon srmCopy, SURL entry is inserted to the target name space, and any methods that access the target SURL such as srmLs, srmBringOnline and srmPrepareToGet must return SRM_FILE_BUSY at the file level. If another srmPrepareToPut or srmCopy were requested on the same target SURL, SRM_FILE_BUSY must be returned if the target SURL can be overwritten, otherwise SRM_DUPLICATION_ERROR must be returned at the file level.

w)    Input parameter overwriteOption is assumed to be NEVER when not specified.

 

                                                     

5.7.3. Return Status Code

For request level return status,

SRM_REQUEST_QUEUED

§  successful request submission and acceptance. All file requests are on the queue. Request token must be returned.

SRM_REQUEST_INPROGRESS

§  Some files are completed, and some files are still on the queue. Details are on the files status. Request token must be returned.

SRM_SUCCESS

§  All requests are successfully completed. All source SURLs are copied into the target destination successfully.

SRM_PARTIAL_SUCCESS

§  All requests are completed. Some file request is successfully copied into the target destination, and some file request is failed. Details are on the files status.

SRM_AUTHENTICATION_FAILURE

§  SRM server failed to authenticate the client

SRM_AUTHORIZATION_FAILURE

§  client is not authorized to submit the request

§  Client is not authorized to copy files into the space that client provided with targetSpaceToken or targetFileRetentionPolicyInfo

SRM_INVALID_REQUEST

§  If both input parameters targetSpaceToken and TRetentionPolicyInfo are provided, then their types must match exactly.

§  targetSpaceToken does not refer to an existing known space in the SRM server.

SRM_SPACE_LIFETIME_EXPIRED

§  space associated with the targetSpaceToken is expired.

SRM_EXCEED_ALLOCATION

§  space associated with the targetSpaceToken is not enough to hold all requested SURLs.

SRM_NO_USER_SPACE

§  user space is not enough to hold all requested SURLs.

SRM_NO_FREE_SPACE

§  SRM space is not enough to hold all requested SURLs for free.

SRM_INTERNAL_ERROR

§  SRM has an internal transient error, and client may try again.

SRM_NOT_SUPPORTED

§  SRM server does not support the given input parameters. For example, client requested desiredFileStorageType that is not supported by the SRM server.

§  targetFileRetentionPolicyInfo does not refer to a supported retention policy in the SRM server.

§  Directory operation is not supported in the SRM server.

§  Recursive directory operation is not supported in the SRM server.

§  any input parameter is not supported in the SRM server

§  a particular type of an input parameter is not supported in the SRM server

§  function is not supported in the SRM server

SRM_FAILURE

§  all files requests are failed.

§  any other request failure. Explanation needs to be filled for details.

 

For file level return status,

SRM_SUCCESS

§  successful request completion for the file. The source SURL is copied into the target destination targetSURL successfully, and lifetime on the targetSURL is started.

SRM_REQUEST_QUEUED

§  file request is on the queue.

SRM_REQUEST_INPROGRESS

§  file request is being served.

SRM_FILE_LOST

§  the request file (sourceSURL) is permanently lost.

SRM_FILE_BUSY

§  client requests for files at the source (sourceSURL) which there is an active srmPrepareToPut (no srmPutDone is not yet called) for.

§  client requests for files at the target (targetSURL) which there is an active srmPrepareToPut (no srmPutDone is not yet called) or srmCopy for.

SRM_FILE_UNAVAILABLE

§  the request file (sourceSURL)  is temporarily unavailable.

SRM_FILE_LIFETIME_EXPIRED

§  lifetime on targetSURL has expired, but the file is still in the cache.

SRM_INVALID_PATH

§  sourceSUR does not exist

§  targetSURL does not refer to a valid path.

SRM_DUPLICATION_ERROR

§  targetSURL refers to an existing SURL and overwriting is not allowed.

SRM_AUTHORIZATION_FAILURE

§  Client is not authorized to copy files from sourceSURL

§  Client is not authorized to copy files into targetSURL

§  Client is not authorized to copy files into the space that client provided with targetSpaceToken or targetFileRetentionPolicyInfo

SRM_ABORTED

§  The requested file has been aborted.

SRM_RELEASED

§  The requested file has been released.

SRM_NO_USER_SPACE

§  user space is not enough to hold the requested SURL.

SRM_NO_FREE_SPACE

§  SRM space is not enough to hold the requested SURL for free.

SRM_FAILURE

§  any other request failure. Explanation needs to be filled for details.

§  The file request would not be able to be completed within the totalRequestTime.

§  The requested file has been suspended because the request has timed out.

 

 

 

5.8. srmStatusOfCopyRequest

 

This function is used to check the status of the previously requested srmCopy. Request token from srmCopy must be provided.

 

5.8.1. Parameters

 

                In:           string                                                     requestToken,

                                string                                                     authorizationID,

                                anyURI []                                             arrayOfSourceSURLs,

                                anyURI []                                             arrayOfTargetSURLs,

 

                Out:       TReturnStatus                                   returnStatus,

TCopyRequestFileStatus[]           arrayOfFileStatuses,

                                int                                                           remainingTotalRequestTime

 

5.8.2. Notes on the Behavior

a)      If arrayOfSourceSURLs and/or arrayOfTargetSURLs are not provided, return status for all file requests in the request.

b)      If the target space for the requested files is full, then SRM_EXCEED_ALLOCATION, SRM_NO_USER_SPACE, or SRM_NO_FREE_SPACE must be returned.

c)       SRM must fail (SRM_FAILURE) only if all files in the request failed.

d)      totalRequestTime means: All the file transfer for this request must be complete within this totalRequestTime.  Otherwise, SRM_REQUEST_TIMED_OUT must be returned as the request status code with individual file status of SRM_FAILURE with an appropriate explanation.

e)      Output parameter remainingTotalRequestTime indicates how long the desiredTotalRequestTime is left. If remainingTotalRequestTime is 0 (zero), the request has been timed out. If remainingTotalRequestTime is a negative value (-1), it would mean that each file request will be tried at least once.

f)       Streaming mode is allowed. If streaming mode is supported and there is not enough space to hold the request or partially hold the request, the SRM server returns SRM_REQUEST_QUEUED and keeps trying the request for the duration of desiredTotalRequestTime from the request. remainingTotalRequestTime is being returned. In the output parameter of explanation in returnStatus, the server may make explicit that the retry is being done. If streaming mode is not supported, the server returns SRM_NO_USER_SPACE or SRM_NO_FREE_SPACE at the file level and SRM_PARTIAL_SUCCESS (if some file requests were successful) or SRM_FAILURE at the request level. Clients may need to clean up the target space when target space token was provided.

g)      Upon srmCopy, SURL entry is inserted to the target name space, and any methods that access the target SURL such as srmLs, srmBringOnline and srmPrepareToGet must return SRM_FILE_BUSY at the file level. If another srmPrepareToPut or srmCopy were requested on the same target SURL, SRM_FILE_BUSY must be returned if the target SURL can be overwritten, otherwise SRM_DUPLICATION_ERROR must be returned at the file level.

h)      srmRm may remove SURLs even if the statuses of the SURLs are SRM_FILE_BUSY. In this case, the status for srmCopy request must return SRM_INVALID_PATH upon status request.

i)        Output parameter returnStatus must always refer to the request status of the whole request, even if a subset of the whole request was specified in the input for specific file statuses.

 

5.8.3. Return Status Code

For request level return status,

SRM_SUCCESS

§  All requests are successfully completed. All source SURLs are copied into the target destination successfully.

SRM_REQUEST_QUEUED

§  successful request submission and all files request is still on the queue

SRM_REQUEST_INPROGRESS

§  Some files are completed, and some files are still on the queue. Details are on the files status.

SRM_PARTIAL_SUCCESS

§  All requests are completed. Some file request is successfully copied into the target destination, and some file request is failed. Details are on the files status.

SRM_AUTHENTICATION_FAILURE

§  SRM server failed to authenticate the client

SRM_AUTHORIZATION_FAILURE

§  client is not authorized to submit the request

SRM_INVALID_REQUEST

§  requestToken does not refer to an existing known request in the SRM server.

§  targetSpaceToken does not refer to an existing known space in the SRM server.

SRM_TOO_MANY_RESULTS

§  Request produced too many results that SRM server cannot handle, and arrayOfSourceURLs and arrayOfTargetURLs cannot fit the results to return.

SRM_REQUEST_TIMED_OUT

§  Total request time is over and the rest of the request is failed.

SRM_REQUEST_SUSPENDED

§  The request is suspended.

SRM_SPACE_LIFETIME_EXPIRED

§  space associated with the targetSpaceToken is expired.

SRM_EXCEED_ALLOCATION

§  space associated with the targetSpaceToken is not enough to hold all requested SURLs.

SRM_NO_USER_SPACE

§  Insufficient space left in the space that is associated with spaceToken.

SRM_NO_FREE_SPACE

§  When client does not specify the spaceToken, SRM uses a default space. The default space is insufficient to accommodate the request.

SRM_ABORTED

§  The request has been aborted.

SRM_INTERNAL_ERROR

§  SRM has an internal transient error, and client may try again.

SRM_NOT_SUPPORTED

§  SRM server does not support the given input parameters. For example, client requested bbftp for the only transfer protocol, but SRM cannot support that. Client requested desiredFileStorageType that is not supported by the SRM server.

§  targetFileRetentionPolicyInfo does not refer to a supported retention policy in the SRM server.

§  Overwrite option is not supported in the SRM server.

§  Directory operation is not supported in the SRM server.

§  Recursive directory operation is not supported in the SRM server.

§  any input parameter is not supported in the SRM server

§  a particular type of an input parameter is not supported in the SRM server

§  function is not supported in the SRM server

SRM_FAILURE

§  all files requests are failed.

§  any other request failure. Explanation needs to be filled for details.

 

For file level return status,

SRM_SUCCESS

§  successful request completion for the file. The source SURL is copied into the target destination targetSURL successfully, and lifetime on the targetSURL is started.

SRM_REQUEST_QUEUED

§  file request is on the queue.

SRM_REQUEST_INPROGRESS

§  file request is being served.

SRM_FILE_LOST

§  the request file (sourceSURL) is permanently lost.

SRM_FILE_BUSY

§  client requests for files at the source (sourceSURL) which there is an active srmPrepareToPut (no srmPutDone is not yet called) for.

§  client requests for files at the target (targetSURL) which there is an active srmPrepareToPut (no srmPutDone is not yet called) or srmCopy for.

SRM_FILE_UNAVAILABLE

§  the request file (sourceSURL)  is temporarily unavailable.

SRM_FILE_LIFETIME_EXPIRED

§  lifetime on targetSURL has expired, but the file is still in the cache.

SRM_INVALID_PATH

§  sourceSUR does not exist

§  targetSURL does not refer to a valid path.

SRM_DUPLICATION_ERROR

§  targetSURL refers to an existing SURL and overwriting is not allowed.

SRM_AUTHORIZATION_FAILURE

§  Client is not authorized to copy files from sourceSURL

§  Client is not authorized to copy files into targetSURL

§  Client is not authorized to copy files into the space that client provided with targetSpaceToken or targetFileRetentionPolicyInfo

SRM_ABORTED

§  The requested file has been aborted.

SRM_RELEASED

§  The requested file has been released.

SRM_REQUEST_SUSPENDED

§  File request is suspended.

SRM_NO_USER_SPACE

§  user space is not enough to hold the requested SURL.

SRM_NO_FREE_SPACE

§  SRM space is not enough to hold the requested SURL for free.

SRM_FAILURE

§  any other request failure. Explanation needs to be filled for details.

§  The file request would not be able to be completed within the totalRequestTime.

§  The requested file has been suspended because the request has timed out.

 

 

5.9. srmReleaseFiles

 

This function is used to release pins on the previously requested “copies” (or “state”) of the SURL. This function normally follows srmPrepareToGet or srmBringOnline functions.

 

5.9.1. Parameters

 

                In:           string                                                     requestToken,

                                string                                                     authorizationID,

                                anyURI []                                             arrayOfSURLs,

                                Boolean                                               doRemove

 

                Out:       TReturnStatus                                   returnStatus,

TSURLReturnStatus[]                     arrayOfFileStatuses

               

5.9.2. Notes on the Behavior

a)      doRemove by default is false. If remove is true, the pin on the file is released, the “copy” or “state” is removed and SRM may release the resource.

b)      Directory is okay for SURL. In such case, it will release all files recursively in the directory.

c)       If requestToken is not provided and SURLs are provided, then the SRM will release all the files specified by the SURLs owned by the caller, regardless of the requestToken.

d)      If requestToken is provided and SURLs are not provided, then the SRM will release all the files in the request that is associated with the requestToken.

e)      At least one of requestToken and SURLs must be provided.

f)       If requestToken is not provided, then authorizationID may be needed as an additional verification method for the client authorization to release files.  It may be inferred or provide in the call.

g)      srmReleaseFiles is only valid after srmPrepareToGet or srmBringOnline operations. To release TURLs after a srmPrepareToPut, srmAbortRequest or srmAbortFiles must be used. If a client submits srmReleaseFiles after srmPrepareToPut or srmPutDone, then the SRM server returns SRM_INVALID_REQUEST.

 

5.9.3. Return Status Code

For request level return status,

SRM_SUCCESS

§  All requests are successfully completed. All SURLs are released successfully.

SRM_PARTIAL_SUCCESS

§  All requests are completed. Some SURLs are successfully released, and some SURLs are failed. Details are on the files status.

SRM_AUTHENTICATION_FAILURE

§  SRM server failed to authenticate the client

SRM_AUTHORIZATION_FAILURE

§  client is not authorized to release files

SRM_INVALID_REQUEST

§  arrayOfSURLs is empty.

§  requestToken does not refer to an existing known request of srmPrepareToGet or srmBringOnline in the SRM server.

SRM_INTERNAL_ERROR

§  SRM has an internal transient error, and client may try again.

SRM_FAILURE

§  All files requests are failed.

§  any other request failure. Explanation needs to be filled for details.

SRM_NOT_SUPPORTED

§  function is not supported in the SRM

§  input parameter doRemove is not supported in the SRM. srmRm must be used.

 

For file level return status,

SRM_SUCCESS

§  successful request completion for the SURL. SURL is released successfully.

SRM_INVALID_PATH

§  SURL does not refer to an existing file

SRM_AUTHORIZATION_FAILURE

§  client is not authorized to release SURL

SRM_LAST_COPY

§  SURL is the last copy when remove flag is on

SRM_FILE_LIFETIME_EXPIRED

§  SURL is expired already.

SRM_ABORTED

§  The requested file has been aborted.

SRM_FAILURE

§  any other request failure. Explanation needs to be filled for details.

 

 

5.10. srmPutDone

 

srmPutDone() is used to notify the SRM that the client completed a file transfer to the TransferURL in the allocated space. This call should normally follow srmPrepareToPut.

 

5.10.1. Parameters

 

                In:           string                                                     requestToken,

                                string                                                     authorizationID,

                                anyURI []                                             arrayOfSURLs

 

                Out:       TReturnStatus                                   returnStatus,

TSURLReturnStatus[]                     arrayOfFileStatuses

                                 

5.10.2. Notes on the Behavior

a)      Called by client after srmPrepareToPut() prepares the TURL and the client completes the file transfer into the prepared TURL.

b)      srmRm may remove SURLs even if the statuses of the SURLs are SRM_FILE_BUSY. In this case, SRM_INVALID_PATH must be returned upon srmPutDone request.

c)       If any additional srmPutDone is requested on the same SURL, SRM_DUPLICATION_ERROR must be returned at the file level.

d)      When srmPutDone is called on a subset of srmPrepareToPut request, the request level status for the srmPutDone must refer to the subset of the request that srmPutDone was called on.

e)      When srmPutDone is called without any file transfers into the TURL, SRM_INVALID_PATH must be returned at the file level status.

f)       Before srmPutDone is called, if one of the parent directories is “moved”, srmPutDone on the old SURL must fail. The SURL must reflect the changes from the directory move.

 

5.10.3. Return Status Code

For request level return status,

SRM_SUCCESS

§  All requests are successfully completed. TURLs contain data, and file lifetimes on the SURLs start.

SRM_PARTIAL_SUCCESS

§  All requests are completed. Some file requests are successfully completed, and some file requests are failed. Details are on the files status.

SRM_AUTHENTICATION_FAILURE

§  SRM server failed to authenticate the client

SRM_AUTHORIZATION_FAILURE

§  client is not authorized to call the request specified by the requestToken

SRM_INVALID_REQUEST

§  arrayOfSURLs is empty.

§  requestToken is empty.

§  requestToken does not refer to an existing known request in the SRM server.

SRM_REQUEST_TIMED_OUT

§  Total request time is over and the request is failed.

SRM_ABORTED

§  The request has been aborted.

SRM_INTERNAL_ERROR

§  SRM has an internal transient error, and client may try again.

SRM_FAILURE

§  All files requests are failed.

§  any other request failure. Explanation needs to be filled for details.

SRM_NOT_SUPPORTED

§  function is not supported in the SRM

 

For file level return status,

SRM_SUCCESS

§  successful request completion of the “put done” for the targetSURL

SRM_INVALID_PATH

§  SURL does not refer to an existing file request

§  no file transfer was performed on the SURL

SRM_AUTHORIZATION_FAILURE

§  client is not authorized to call the request srmPutDone() on the SURL

SRM_DUPLICATION_ERROR

§  targetSURL exists already.

SRM_FILE_LIFETIME_EXPIRED

§  targetSURL has an expired TURL.

SRM_SPACE_LIFETIME_EXPIRED

§  targetSURL has an expired space allocation.

SRM_ABORTED

§  The requested SURL file has been aborted.

SRM_FAILURE

§  any other request failure. Explanation needs to be filled for details.

 

 

5.11. srmAbortRequest

 

srmAbortRequest() allows clients to prematurely terminate asynchronous requests of any types. It may involve data transfer requests initiated by a call to srmPrepareToGet(), srmBringOnline(), srmPrepareToPut() or srmCopy(). The effect of srmAbortRequest() depends on the type of request. For data transfer request, the SRM will attempt a complete cleanup of running transfers and files in intermediate state.

 

5.11.1. Parameters

 

                In:           string                                     requestToken,

                                string                                     authorizationID

 

                Out:       TReturnStatus                   returnStatus

 

5.11.2. Notes on the Behavior

a)      Terminate all files in the request regardless of the file state. Remove files from the queue, and release cached files if a limited lifetime is associated with the file.

b)      Those files that are brought online with unlimited lifetime will remain in the space where they are brought in and are not removed. Clients need to remove explicitly through srmRm or srmPurgeFromSpace.

c)       Abort must be allowed to all requests with requestToken.

d)      When aborting srmCopy request, the request may contain one source SURL and multiple target SURLs. If the request is aborted by the source SURL, all file request of the same source SURL must be aborted. If the request is aborted by the target SURL, a specific target file request must be aborted, and other file requests from the same source SURL must not be aborted.

e)      When aborting srmPrepareToGet request, all uncompleted files must be aborted, and all successfully completed files must be released.

f)       When aborting srmPrepareToPut request before srmPutDone and before the file transfer, the SURL must not exist as the result of the successful abort on the SURL. Any srmRm request on the SURL must fail.

g)      When aborting srmPrepareToPut request before srmPutDone and after the file transfer, the SURL may exist, and a srmRm request on the SURL may remove the requested SURL.

h)      When aborting after srmPutDone, it must be failed for those files. An explicit srmRm is required to remove those successfully completed files for srmPrepareToPut.

i)        When duplicate abort request is issued on the same request, SRM_SUCCESS may be returned to all duplicate abort requests and no operations on duplicate abort requests are performed.

 

5.11.3. Return Status Code

SRM_SUCCESS

§  successful request completion. Request is aborted successfully.

SRM_PARTIAL_SUCCESS

§  All requests are completed. Some SURLs are successfully aborted, and some SURLs are failed. Some abort may be failed because files were successfully completed already. 

SRM_AUTHENTICATION_FAILURE

§  SRM server failed to authenticate the client

SRM_AUTHORIZATION_FAILURE

§  client is not authorized to abort files in the request specified by the requestToken

SRM_INVALID_REQUEST

§  requestToken does not refer to an existing known request in the SRM server.

SRM_INTERNAL_ERROR

§  SRM has an internal transient error, and client may try again.

SRM_FAILURE

§  any other request failure. Explanation needs to be filled for details.

SRM_NOT_SUPPORTED

§  function is not supported in the SRM

 

 

5.12. srmAbortFiles

 

srmAbortFiles() allows clients  to abort selective file requests from the asynchronous requests of any type.  It may include data transfer requests initiated by a call to srmPrepareToGet(), srmBringOnline(), srmPrepareToPut(), or srmCopy(). The effect of a srmAbortFiles() depends on the type of the request.

 

5.12.1. Parameters

 

                In:           string                                                     requestToken,

                                anyURI []                                             arrayOfSURLs,

                                string                                                     authorizationID

 

                Out:       TReturnStatus                                   returnStatus,

TSURLReturnStatus[]                     arrayOfFileStatuses

 

5.12.2. Notes on the Behavior

a)      Abort all files in this call regardless of the state.

b)      When aborting srmCopy request, the request may contain one source SURL and multiple target SURLs. If the request is aborted by the source SURL, all file request of the same source SURL must be aborted. If the request is aborted by the target SURL, a specific target file request must be aborted, and other file requests from the same source SURL must not be aborted.

c)       When aborting srmPrepareToGet file requests, all uncompleted files must be aborted, and all successfully completed files must be released.

d)      When aborting srmPrepareToPut file requests before srmPutDone and before the file transfers, the SURL must not exist as the result of the successful abort on the SURL. Any srmRm request on the SURL must fail.

e)      When aborting srmPrepareToPut file requests before srmPutDone and after the file transfer, the SURL may exist, and a srmRm request on the SURL may remove the requested SURL.

f)       When aborting after srmPutDone, it must be failed for those files. An explicit srmRm is required to remove those successfully completed files for srmPrepareToPut.

g)      This method must not change the request level status of the completed requests. Once a request is completed, the status of the request remains the same.

h)      When duplicate abort file request is issued on the same files, SRM_SUCCESS may be returned to all duplicate abort file requests and no operations on duplicate abort file requests are performed.

 

5.12.3. Return Status Code

For request level return status,

SRM_SUCCESS

§  successful request completion. All SURLs are aborted successfully.

SRM_PARTIAL_SUCCESS

§  All requests are completed. Some SURLs are successfully aborted, and some SURLs are failed. Details are on the files status.

SRM_AUTHENTICATION_FAILURE

§  SRM server failed to authenticate the client

SRM_AUTHORIZATION_FAILURE

§  client is not authorized to abort files in the request specified by the requestToken

SRM_INVALID_REQUEST

§  arrayOfSURLs is empty.

§  requestToken is empty.

§  requestToken does not refer to an existing known request in the SRM server.

SRM_INTERNAL_ERROR

§  SRM has an internal transient error, and client may try again.

SRM_FAILURE

§  All files requests are failed.

§  any other request failure. Explanation needs to be filled for details.

SRM_NOT_SUPPORTED

§  function is not supported in the SRM

 

For file level return status,

SRM_SUCCESS

§  successful abort request completion for the SURL. SURL is aborted successfully.

SRM_INVALID_PATH

§  SURL does not refer to an existing file request that is associated with the request token

SRM_FAILURE

§  any other request failure. Explanation needs to be filled for details.

 

 

5.13. srmSuspendRequest

 

srmSuspendedRequest is to suspend a previously submitted active request.

 

5.13.1. Parameters

 

In:           string                                     requestToken

                string                                     authorizationID

               

Out:       TReturnStatus                   returnStatus                     

 

5.13.2. Notes on the Behavior

a)      Suspend all files in this request until srmResumeRequest is issued.

 

5.13.3. Return Status Code

SRM_SUCCESS

§  successful request completion. Request is suspended successfully.

SRM_AUTHENTICATION_FAILURE

§  SRM server failed to authenticate the client

SRM_AUTHORIZATION_FAILURE

§  client is not authorized to suspend the request specified by the requestToken

SRM_INVALID_REQUEST

§  requestToken is empty.

§  requestToken does not refer to an existing known request in the SRM server.

SRM_INTERNAL_ERROR

§  SRM has an internal transient error, and client may try again.

SRM_FAILURE

§  any other request failure. Explanation needs to be filled for details.

SRM_NOT_SUPPORTED

§  function is not supported in the SRM server

 

 

5.14. srmResumeRequest

 

srmResumeRequest is to resume previously suspended requestst.

 

5.14.1. Parameters

 

In:           string                                     requestToken,

                string                                     authorizationID

               

Out:       TReturnStatus                   returnStatus                     

 

5.14.2. Notes on the Behavior

a)      Resume the previously suspended request.

 

5.14.3. Return Status Code

SRM_SUCCESS

§  successful request completion. Request is resumed successfully.

SRM_AUTHENTICATION_FAILURE

§  SRM server failed to authenticate the client

SRM_AUTHORIZATION_FAILURE

§  client is not authorized to resume the request specified by the requestToken

SRM_INVALID_REQUEST

§  requestToken is empty.

§  requestToken does not refer to an existing known request in the SRM server.

SRM_INTERNAL_ERROR

§  SRM has an internal transient error, and client may try again.

SRM_FAILURE

§  any other request failure. Explanation needs to be filled for details.

SRM_NOT_SUPPORTED

§  function is not supported in the SRM server

 

 

 

5.15. srmGetRequestSummary

 

srmGetRequestSummary is to retrieve a summary of the previously submitted request.

 

5.15.1. Parameters

 

                In:           string []                                                arrayOfRequestTokens,

                                string                                     authorizationID

 

                Out:       TReturnStatus                   returnStatus

TRequestSummary[]      arrayOfRequestSummaries

 

 

5.15.2. Return Status Code

For request interface level return status,

SRM_SUCCESS

§  All requests are successfully completed. All requests summaries are checked and returned successfully. Details are on the request status.

SRM_PARTIAL_SUCCESS

§  All requests are completed. Summaries of some requests are successfully checked and returned, but some requests summaries are failed. Details are on the request status.

SRM_AUTHENTICATION_FAILURE

§  SRM server failed to authenticate the client

SRM_AUTHORIZATION_FAILURE

§  client is not authorized to get summary of the request specified by the requestToken

SRM_INVALID_REQUEST

§  arrayOfRequestTokens is empty.

SRM_INTERNAL_ERROR

§  SRM has an internal transient error, and client may try again.

SRM_NOT_SUPPORTED

§  function is not supported in the SRM

SRM_FAILURE

§  SRM failed to get summaries of all requests that are associated with request tokens.

§  any other request failure. Explanation needs to be filled for details.

 

For request level return status,

SRM_INVALID_REQUEST

§  requestToken does not refer to an existing known request in the SRM server.

SRM_SUCCESS

§  The request has been completed successfully.

SRM_REQUEST_QUEUED

§  successful request submission and all files request is still on the queue

SRM_REQUEST_INPROGRESS

§  some files are completed, and some files are still on the queue

SRM_REQUEST_TIMED_OUT

§  Total request time is over and the request is failed.

SRM_REQUEST_SUSPENDED

§  The request has been suspended.

SRM_ABORTED

§  The request has been aborted.

SRM_PARTIAL_SUCCESS

§  All requests are completed. Some request is successfully completed, and some request is failed.

SRM_FAILURE

§  The request is failed. Explanation needs to be filled for details.

 

 

5.16. srmExtendFileLifeTime

 

srmExtendFileLifetime() allows clients to extend lifetime of existing SURLs of volatile and durable file storage types or lifetime of pinned files (TURLs and those TURLs are of the results of srmPrepareToGet, srmPrepareToPut or srmBringOnline).

 

5.16.1. Parameters

 

                In:           string                                                     authorizationID,

string                                                     requestToken,

                                anyURI []                                             arrayOfSURLs,

                                int                                                           newFileLifetime,

                                int                                                           newPinLifetime

 

                Out:       TReturnStatus                                   returnStatus,

                                TSURLLifetimeReturnStatus []    arrayOfFileStatuses

 

5.16.2. Notes on the Behavior

a)      This method allows to change only one lifetime at a time (either SURL lifetime by the newFileLifetime or pin lifetime by the newPinLifetime), depending on the presence or absence of the request token. When both newFileLifetime and newPinLifetime are provided in the same request, the request is invalid, and SRM_INVALID_REQUST must be returned.  SURL lifetimes are on SURLs that resulted from the successful srmCopy or srmPrepareToPut followed by srmPutDone, and pin lifetimes are on TURLs or file copies that resulted from srmPrepareToGet, srmPrepareToPut or srmBringOnline.

b)      newPinLifetime and newFileLifetime are relative to the calling time. Lifetime will be set from the calling time for the specified period.

c)       When the requestToken is provided, only pin lifetime is extended with newPinLifetime.

d)      When SURL lifetime is extended with newFileLifetime, the request token must not be specified.

e)      The number of lifetime extensions maybe limited by SRM according to its policies.

f)       If original lifetime is longer than the requested one, then the requested one will be assigned.

g)      When none of lifetime input parameters (newPinLifetime and newFileLifetime) is not specified, the SRM server does not change the lifetimes.

h)      Lifetime cannot be extended on the released files, aborted files, expired files, and suspended files. For example, pin lifetime cannot be extended after  srmPutDone is requested on SURLs after srmPrepareToPut. In such case, SRM_INVALID_REQUEST at the file level must be returned, and SRM_PARTIAL_SUCCESS or SRM_FAILURE must be returned at the request level.

i)        Extending file lifetime on SURL is similar to srmExtendFileLifetimeInSpace.

j)        If input parameters newFileLifetime or newPinLifetime request exceeds the remaining lifetime of the space, then SRM_SUCCESS is returned at the request and file level, and TSURLLifetimeReturnStatus contains the remaining lifetime.

k)      Lifetime extension must fail on SURLs when their status is SRM_FILE_BUSY.

l)        This method intends to negotiate a request of extension of file or pin lifetime. When new lifetime request exceeds the remaining lifetime of the space where SURLs are, SRM_SUCCESS is returned at the request level and at the file level, and TSURLLifetimeReturnStatus includes the remaining lifetime.

 

5.16.3. Return Status Code

For request level return status,

SRM_SUCCESS

§  All requests are successfully completed. All SURLs or TURLs associated with SURLs in the specified request have an extended lifetime. Details are on the files status.

SRM_PARTIAL_SUCCESS

§  All requests are completed. Lifetimes on some SURLs or TURLs are successfully extended, and lifetimes on some SURLs or TURLs are failed to be extended. Details are on the files status.

SRM_AUTHENTICATION_FAILURE

§  SRM server failed to authenticate the client

SRM_AUTHORIZATION_FAILURE

§  client is not authorized to extend file lifetime

SRM_INVALID_REQUEST

§  requestToken does not refer to an existing known request in the SRM server.

§  requestToken is not provided, and extending pinning lifetime of TURLs associated with SURLs require requestToken.

SRM_INTERNAL_ERROR

§  SRM has an internal transient error, and client may try again.

SRM_FAILURE

§  All files requests are failed.

§  any other request failure. Explanation needs to be filled for details.

SRM_NOT_SUPPORTED

§  function is not supported in the SRM

 

For file level return status,

SRM_SUCCESS

§  successful request completion for the SURL. SURL or TURL associated with the SURL in the request has an extended lifetime.

SRM_INVALID_PATH

§  SURL does not refer to an existing file

§  SURL does not refer to an existing file request that is associated with the request token

SRM_FILE_LIFETIME_EXPIRED

§  Lifetime on SURL is expired already.

SRM_ABORTED

§  The requested file has been aborted.

SRM_RELEASED

§  The requested file has been released.

SRM_INVALID_REQUEST

§  Attempt to extend pin lifetimes on TURLs that have been already expired.

SRM_FAILURE

§  The requested file has been suspended because the request has timed out.

§  any other request failure. Explanation needs to be filled for details.

 

 

 

5.17. srmGetRequestTokens

 

srmGetRequestTokens retrieves request tokens for the client’s requests, given client provided request description. This is to accommodate lost request tokens. This can also be used for getting all request tokens.

 

5.17.1. Parameters

                In:           string                                                     userRequestDescription,

                                string                                                     authorizationID

 

Out:       TReturnStatus                                   returnStatus

TRequestTokenReturn[]               arrayOfRequestTokens

 

 

5.17.2. Notes on the Behavior

a)      If userRequestDescription is null, returns all requests the client has.

b)      If the user assigned the same description to multiple requests, the client may get back multiple request tokens each with the time the request was made.

 

5.17.3. Return Status Code

SRM_SUCCESS

§  successful request completion. Request tokens are returned successfully.

SRM_AUTHENTICATION_FAILURE

§  SRM server failed to authenticate the client

SRM_AUTHORIZATION_FAILURE

§  client is notauthorized to get request tokens specified by the userRequestDescription

SRM_INVALID_REQUEST

§  userRequestDescription does not refer to any existing known requests

SRM_INTERNAL_ERROR

§  SRM has an internal transient error, and client may try again.

SRM_FAILURE

§  any other request failure. Explanation needs to be filled for details.

SRM_NOT_SUPPORTED

§  function is not supported in the SRM

 


 

6. Discovery Functions

 

summary:

srmGetTransferProtocols

srmPing

 

 

6.1. srmGetTransferProtocols

 

This function is to discover what transfer protocols are supported by the SRM.

 

6.1.1. Parameters

 

                In:           string                                                     authorizationID,

 

                Out:       TReturnStatus                                   returnStatus,

                                TSupportedTransferProtocol[]   protocolInfo

 

 

6.1.2. Notes on the Behavior

a)      srmGetTransferProtocols() returns the supported file transfer protocols in the SRM with any additional information about the transfer protocol.

 

6.1.3. Return Status Code

SRM_SUCCESS

§  successful request completion. List of supported transfer protocols are returned successfully.

SRM_AUTHENTICATION_FAILURE

§  SRM server failed to authenticate the client

SRM_AUTHORIZATION_FAILURE

§  client is not authorized to request storage information

SRM_INTERNAL_ERROR

§  SRM has an internal transient error, and client may try again.

SRM_NOT_SUPPORTED

§  function is not supported in the SRM

SRM_FAILURE

§  any other request failure. Explanation needs to be filled for details.

 

 

6.2. srmPing

 

This function is used to check the state of the SRM. It works as an “are you alive” type of call.

 

6.2.1. Parameters

 

                In:           string                                                     authorizationID,

 

                Out:       string                                                     versionInfo

                                TExtraInfo[]                                        otherInfo

 

 

6.2.2. Notes on the Behavior

a)      srmPing() returns a string containing SRM v2.2 version number as a minimal “up and running” information.  For this particular SRM v2.2 version, it must be “v2.2”.  Other versions may have “v1.1”, “v3.0”, and so on.

b)      Any additional information about the SRM can be provided in the output parameter otherInfo.

 

 


7. Appendix

 

7.1. Status Code Specification

 

Note:

 


 

7.2. SRM WSDL discovery method

 

May 1, 2003

 

A) SURL format:

srm://host[:port]/[soap_end_point_path?SFN=]site_file_name

 

where […] means optional, and letters in bold are fixed.

 

We note if the SURL contains the soap_end_point_path, then  it is not possible to change the soap endpoint without changing all the previously published SURLs.

 

Example SURLs:

 

Without soap_end_point_path:

srm://dm.lbl.gov:4001/ABC/file_x

 

with soap_end_point_path:

srm://dm.lbl.gov:4001/srm_servlet?SFN=ABC/file_x

 

 

B) Given that soap-end-point-path clause is provided, then the soap endpoint is:

https://host[:port]/soap_end_point_path

 

C)  If port is missing, the default port assumed is 8443, which is the port for https with GSI.

 

The discussion below assumes no endpoint in the SURL, and shows how the soap endpoints and wsdl can be found given an SURL 

 

 

Issues:

 

  1. We wish to have a way of finding the SRM WSDL for multiple versions from the SURL.

 

  1. We wish to support clients that know what SRM version they want to use.  For example, a client that uses version 1.1, should be able to got the WSDL and/or the SOAP endpoint for it directly.

 

  1. We wish to have a default where an SRM version number is not mentioned.  The version returned in this case is whatever the SRM currently supports, or if multiple versions are supported, the SRM chooses what to return.

 

  1. We wish to allow a file accessed by a previous SRM version to be accessed by a future SRM version without having to change the SURL.  Furthermore, if the file can be accessed by either version simultaneously (that depend on the SRM implementation) that should be possible too.

 

  1. We wish to have a way for a client to find out which version the SRM supports and the endpoint without having to read the WSDL.  This is necessary in a changing world, where new version can be introduced. 

 

  1. We wish to have a client that can use multiple SRM versions to find out which SRM version is supported by the SRM.  This is probably the most realistic scenario, since we cannot expect all SRMs to support the same version at any one time.

 

  1. We wish to have a client find out which SRM versions are supported for accessing a particular file, in case that files can be accessed by multiple SRM versions simultaneously.  This is related to point 3 above.

 

This is a long wish list, but the proposed solution is simple.  We assume that the WSDL will contain the version number.  First, we propose that every SRM WSDL starts with:

SRM version number--> (e.g. <!--SRM version 2.1.3-->)

 

Now, the solution is as follows:

 

Give an SURL: srm://host[:port]/path/file (e.g. srm://dm.lbl.gov:4001/ABC/file_x)

The following can be derived:

Case 1)

For clients that know what SRM versions they want to use:

https://host:port/srm/srm.version.wsdl

https://host:port/srm/srm.version.endpoint

 

For example, given the SURL above, and the client uses version 1.1, you derive:

https://dm.lbl.gov:4001/srm/srm.1.1.wsdl

https://dm.lbl.gov:4001/srm/srm.1.1.endpoint

 

Note: the endpoint returned can be any URI, e.g.: https://gizmo.lbl.gov:10001/srm/v1.0

or:  https://dm.lbl.gov:12345/servlet/srm.1.1)

 

Case 2)

For clients that don’t know the version, and want to use the default:

https://host:port/srm/srm.wsdl

https://host:port/srm/srm.endpoint

 

For the example above:

https://dm.lbl.gov:4001/srm/srm.wsdl

https://dm.lbl.gov:4001/srm/srm.endpoint

 

Case 3)

For clients that want to find out the SRM version and endpoint without getting the entire WSDL:

https://host:port/srm/srm.info

 

The srm.info file will contain:

<!--SRM version number-- --srmEndpoint-->

For example:

<!--SRM version 2.1.3-- -- https://gizmo.lbl.gov:10001/srm-->

 

Case 4)

For servers that support multiple srm version accessing the SAME file:

The same format as above repeating for each srm version.

For example:

<!--SRM version 1.1-- -- https://sdm.lbl.gov:5005/srm-->

<!--SRM version 2.1.3-- -- https://gizmo.lbl.gov:10001/srm-->

 

To summarize, the following is what should be supported for WSDL and endpoint discovery:

 

Given an SURL:

srm://host[:port]/site_file_name

 

The following can be derived:

 

a) https://host[:port]/srm/srm[.version].wsdl

b) https://host[:port]/srm/srm[.version].endpoint

c) https://host[:port]/srm/srm.info

Where the content have the format repeated as many time as there are supported versions:

<!--SRM version number-- --srmEndpoint-->

 

-------------------------------------------


7.3. Changes log

 

In regards to the discussion with WLCG Data Management Coordination Group for the requirements of the LHC experiments of the Grid Storage Interfaces, changes were made to the SRM v2.1.2 specification. The changes are based on the 2-day meeting in May, 2006.  The SRM version 2.2 changes extend and update the SRM v2.1.2 specification. 

 

WSDL and Specification finalized: June 20, 2006

Revision history to the specification: July 3, 2006

                                                            July 6, 2006,

                                                            September 27, 2006 (includes WSDL changes),

                                                            December 15, 2006

                                                            January 22, 2007

                                                                  April 2, 2007

 

All changes after the above date are grouped separately by dates.

 

7.3.1. June 20, 2006  from v2.1.1 to v2.2

 

7.3.1.1. In general

 

7.3.1.2. In the Defined Structure:

 

7.3.1.3. In the Space Reservation Functions:

 

7.3.1.4. In the Permission Functions:

 

7.3.1.5. In the Directory Functions:

 

7.3.1.6. In the Data Transfer Functions:

 

7.3.1.7. In the Information Discovery Functions:

 

7.3.2. July 3, 2006

 

7.3.3. July 6, 2006

 

7.3.4. September 27, 2006

 

7.3.5. December 15, 2006

o    From srmGetRequestID to srmGetRequestTokens

o    SRM_FILE_BUSY is added

o    SRM_FILE_LIFETIME_EXPIRED is added

o    SRM_REQUEST_INPROGRESS is returned at the request level and file level.

o    A comment of “Operation on the path such as browsing the top directory may be prohibited” is added to the SRM_INVALID_PATH.

o    SRM_REQUEST_INPROGRESS is returned at the request level and file level.

o    b) will be changed to OUTPUT or CUSTODIAL retention quality space, from durable or permanent space which no longer exists as definitions.

o    If space is being released with forceFileRelease option while SURLs are being created with srmPrepareToPut or srmCopy, the file is removed and SRM_INVALID_PATH must be returned by the srmPutDonesrmStatusOfPutRequest, or srmStatusOfCopyRequest when the file is volatile. If the file is permanent type, the file is moved to the default space, and the space would be successfully released. The subsequent srmPutDone, srmStatusOfPutRequest, or srmStatusOfCopyRequest would be successful.

o    If space is being released without forceFileRelease option while SURLs are being created with srmPrepareToPut or srmCopy, SRM_FAILURE must be returned in srmReleaseSpace.

o    If requestToken is not provided and SURLs are provided, then the SRM will release all the files specified by the SURLs owned by the caller, regardless of the requestToken.

o    If requestToken is provided and SURLs are not provided, then the SRM will release all the files in the request that is associated with the requestToken.

o    At least one of requestToken and SURLs must be provided.

o    If requestToken is not provided, then authorizationID may be needed as an additional verification method for the client authorization to release files.  It may be inferred or provide in the call.

o    srmReleaseFiles is only valid after srmPrepareToGet or srmBringOnline operations. To release TURLs after a srmPrepareToPut, srmAbortRequest or srmAbortFiles must be used. If a client submits srmReleaseFiles after srmPrepareToPut or srmPutDone, then the SRM server returns SRM_INVALID_REQUEST.

o    This method allows to change only one lifetime at a time (either SURL lifetime by the newFileLifetime or pin lifetime by the newPinLifetime), depending on the presence or absence of the request token. SURL lifetimes are on SURLs that resulted from the successful srmCopy or srmPrepareToPut followed by srmPutDone, and pin lifetimes are on TURLs or file copies that resulted from srmPrepareToGet, srmPrepareToPut or srmBringOnline

o    When the requestToken is provided, only pin lifetime is extended with newPinLifetime.

o    When SURL lifetime is extended with newFileLifetime, the request token must not be specified.

o    When lifetime input parameters (newPinLifetime or newFileLifetime) are not specified, the SRM server uses its default value.

o    Lifetime cannot be extended on the released files, aborted files, expired files, and suspended files. For example, pin lifetime cannot be extended after  srmPutDone is requested on SURLs after srmPrepareToPut. In such case, SRM_INVALID_REQUEST at the file level must be returned, and SRM_PARTIAL_SUCCESS or SRM_FAILURE must be returned at the request level.

o    If input parameters newFileLifetime or newPinLifetime request exceeds the remaining lifetime of the space, then SRM_SUCCESS is returned at the request and file level, and TSURLLifetimeReturnStatus contains the remaining lifetime.

o    Lifetime extension must fail on SURLs when their status is SRM_FILE_BUSY.

o    SRM_INVALID_REQUEST is added at the file level.

o    If input parameters newLifetime request exceed the remaining lifetime of the space, then SRM_SUCCESS is returned at the request and file level, and TSURLLifetimeReturnStatus contains the remaining lifetime.

o    Lifetime extension must fail on SURLs when their status is SRM_FILE_BUSY.

o    arrayOfSURLs are optional. When SURLs are not provided, all files in the space must have the new extended lifetimes.

o    This method applied only to SURLs, and output parameter pinLifetime in TSURLLifetimeReturnStatus must be null

o    Output parameter, lifetimeGranted is clarified as it is relative to the calling time.

o    includes SRM_REQUEST_INPROGRESS as a valid return status.

o    Data type of input parameter desiredLifetimeOfReservedSpace is corrected to be int.

o    Optional input parameters in TTransferParameters may collide with the characteristics of the space specified. In this case, TTransferParameters as an input parameter must be ignored.

o    description about the unusedSize is added.

o    SRM_EXCEED_ALLOCATION is added at the space level.

o    srmRm will remove SURLs even if the statuses of the SURLs are SRM_FILE_BUSY. In this case, operations such as srmPrepareToPut or srmCopy that holds the SURL status as SRM_FILE_BUSY must return SRM_INVALID_PATH upon status request or srmPutDone.

o    srmSetPermission will modify permissions on SURLs even if the statuses of the SURLs are SRM_FILE_BUSY.

o    srmMv must fail on SURL that its status is SRM_FILE_BUSY, and SRM_INVALID_REQUEST must be returned.

o    If input parameter desiredTotalRequestTime is 0 (zero), each file request will be tried at least once.  Negative value is invalid.

o    Output parameter remainingTotalRequestTime indicates how long the desiredTotalRequestTime is left. If remainingTotalRequestTime is 0 (zero), the request has been timed out. If remainingTotalRequestTime is a negative value (-1), it would mean that each file request will be tried at least once.

o    If input parameter desiredTotalRequestTime is 0 (zero), each file request will be tried at least once.  Negative value is not valid

o    Output parameter remainingDeferredStartTime indicates how long the deferredStartTime is left, if supported. Negative value is not valid.

o    Output parameter remainingTotalRequestTime indicates how long the desiredTotalRequestTime is left. If remainingTotalRequestTime is 0 (zero), the request has been timed out. If remainingTotalRequestTime is a negative value (-1), it would mean that each file request will be tried at least once.

o    comments added: TURLs will not be valid any more after the desiredPinLifetime is over if srmPutDone or srmAbortRequest is not submitted on the SURL before expiration.

o    Upon srmPrepareToPut, SURL entry is inserted to the name space, and any methods that access the SURL such as srmLs, srmBringOnline and srmPrepareToGet must return SRM_FILE_BUSY at the file level. If another srmPrepareToPut or srmCopy were requested on the same SURL, SRM_FILE_BUSY must be returned if the SURL can be overwritten, otherwise SRM_DUPLICATION_ERROR must be returned at the file level.

o    Input parameter desiredFileLifetime is the lifetime of the SURL when the file is put into the storage system. It does not refer to the lifetime (expiration time) of the TURL. Lifetime on SURL starts when successrul srmPutDone is executed.

o    If input parameter desiredTotalRequestTime is 0 (zero), each file request will be tried at least once.  Negative value is invalid.

o    Output parameter remainingTotalRequestTime indicates how long the desiredTotalRequestTime is left. If remainingTotalRequestTime is 0 (zero), the request has been timed out. If remainingTotalRequestTime is a negative value (-1), it would mean that each file request will be tried at least once.

o    comments added: TURLs will not be valid any more after the pin lifetime is over if srmPutDone or srmAbortRequest is not submitted on the SURL before expiration.

o    Lifetime on SURL starts when successrul srmPutDone is executed

o    SRM_ABORTED is returned at the request level at the successful abort of the request.

o    SRM_NO_USER_SPACE, SRM_NO_FREE_SPACE and SRM_FILE_BUSY are added at the file level status.

o    srmRm may remove SURLs even if the statuses of the SURLs are SRM_FILE_BUSY. In this case, the status for srmPrepareToPut request must return SRM_INVALID_PATH upon status request or srmPutDone.

o    srmRm may remove SURLs even if the statuses of the SURLs are SRM_FILE_BUSY. In this case, SRM_INVALID_PATH must be returned upon srmPutDone request.

o    If any additional srmPutDone is requested on the same SURL, SRM_DUPLICATION_ERROR must be returned at the file level.

o    Upon srmCopy, SURL entry is inserted to the target name space, and any methods that access the target SURL such as srmLs, srmBringOnline and srmPrepareToGet must return SRM_FILE_BUSY at the file level. If another srmPrepareToPut or srmCopy were requested on the same target SURL, SRM_FILE_BUSY must be returned if the target SURL can be overwritten, otherwise SRM_DUPLICATION_ERROR must be returned at the file level.

o    If input parameter desiredTotalRequestTime is 0 (zero), each file request will be tried at least once.  Negative value is invalid.

o    Output parameter remainingTotalRequestTime indicates how long the desiredTotalRequestTime is left. If remainingTotalRequestTime is 0 (zero), the request has been timed out. If remainingTotalRequestTime is a negative value (-1), it would mean that each file request will be tried at least once.

o    srmRm may remove SURLs even if the statuses of the SURLs are SRM_FILE_BUSY. In this case, the status for srmCopy request must return SRM_INVALID_PATH upon status request.

o    Includes a statement about the lifetime of the request token.

o    Statement that userRequest[Space]Description may be null, and it is case-sensitive when provided. SRM server is expected to keep it as client provides. It can be reused by the client. It can be used in the srmGetRequest[Space]Tokens function to get back the system assigned request or space tokens. 

o    srmPrepareToGet, srmStatusOfGetRequest, srmBringOnline, srmStatusOfBringOnlineRequest, srmPrepareToPut, srmStatusOfPutRequest, srmCopy, srmStatusOfCopyRequest

o    added comments

o    SRM_NO_USER_SPACE and SRM_NO_FREE_SPACE are added at the file level status.

o    TGetRequestFileStatus, TBringOnlineRequestFileStatus, TPutRequestFileStatus, TCopyRequestFileStatus

o    Negative value, -1, for unknown.

o    TTransferParameters may be provided optionally in the methods such as srmPrepareToGet, srmBringOnline, srmPrepareToPut and srmReserveSpace. Optional input parameters in TTransferParameters may collide with the characteristics of the space specified. In this case, TTransferParameters as an input parameter must be ignored.

o    lifetimeAssigned is the total lifetime that is assigned on the SURL. It includes all SURL lifetime extensions if extended.

o    lifetimeLeft is the remaining lifetime that is left on the SURL.

o    lifetimeAssigned is the total lifetime that is assigned to the space. It includes all space lifetime extensions if extended.

o    lifetimeLeft is the remaining lifetime that is left on the space.

 

7.3.6. January 22, 2007

o    srmCopy has input parameter desiredTargetSURLLifeTime for corresponding WSDL parameter.

o    neither size not time is provided, SRM_INVALID_REQUEST is returned

o    default numOfLevels is 1.

o    Added note (l) for browsing non-existing, non-supported, or system-prohibited file or directory

o    removed file level status SRM_SUCCESS that never happens

o    Removed a duplicate note

o    Behavior contains for both life time and request time, and exceptions are specified.

o    numOfWaitingFiles describes the number of files on the queue.

o    numOfFailedFiles describes the number of failed files and aborted files.

o    numOfCompletedFiles describes the number of successfully completed files, number of failed files and number of aborted files.

o    totalNumFilesInRequest describes the numOfWaitingFiles, numOfCompletedFiles, numOfFailedFiles and number of files in progress.

o    For srmPrepareToPut and srmCopy, input parameter overwriteOption is assumed to be NEVER when not specified.

o    Added for a possible return status for srmStatusOfReserveSpaceRequest, srmStatusOfUpdateSpaceRequest, srmStatusOfChangeSpaceForFilesRequest, srmStatusOfGetRequest, srmStatusOfBringOnlineRequest, srmStatusOfPutRequest and srmStatusOfCopyRequest

o    underline of input parameter arrayOfSURLs is corrected to be optional.

o    added that when both newFileLifetime and newPinLifetime are provided in the same request, the request is invalid, and SRM_INVALID_REQUST must be returned.

o    SRM_PARTIAL_SUCCESS added as a return status to cover a case when some files in a request were aborted, and failed because they were completed successfully already.

o    added: (b) When aborting srmCopy request, the request may contain one source SURL and multiple target SURLs. If the request is aborted by the source SURL, all file request of the same source SURL must be aborted. If the request is aborted by the target SURL, a specific target file request must be aborted, and other file requests from the same source SURL must not be aborted.

o    when input parameter retentionPolicyInfo is not supported by SRM, SRM_NOT_SUPPORTED must be returned.

 

7.3.7. April 6, 2007

o    SRM_REQUEST_QUEUED is added

o    SRM_NOT_SUPPORTED is added at the file level for non-supported top directory browsing

o    Updated: (c) If fullDetailedList is true, the full details are returned.

§ For directories (numOfLevels=0) or a single file , path, size, userPermission, lastModificationTime, type, fileLocality, and lifetimeLeft are required to be returned, similar to unix command ls –l.

§ For directories (numOfLevels=1) , path, size, userPermission, lastModificationTime, and type are required to be returned.

o    Added:  (d)    Moving an SURL to itself results in no operation and SRM_SUCCESS will be returned for no operation.

o    Added: (e)     When moving an SURL to already existing SURL, SRM_DUPLICATION_ERROR must be returned.

o    Added: (d) When only expired volatile files are in the requested directory, srmRmdir must allow the removal of the requested directory regardless of the expired files. The SURL of the expired volatile files must no longer exist in the file system, and may or may not be removed right away physically depending on the internal server policy.

o    Added: (l) This method intends to negotiate a request of extension of file or pin lifetime. When new lifetime request exceeds the remaining lifetime of the space where SURLs are, SRM_SUCCESS is returned at the request level and at the file level, and TSURLLifetimeReturnStatus includes the remaining lifetime.

o    Updated: (g) When none of lifetime input parameters (newPinLifetime and newFileLifetime) is not specified, the SRM server does not change the lifetimes,

o    Udated: (f) If newLifeTime is not specified, the SRM does not change the lifetime.

o    Added SRM_SPACE_LIFETIME_EXPIRED at the request level status

o