**The Storage Resource Manager\
Interface Specification**

**Version 2.2**

**24 May 2008**

+--------------------------+---------------------------------------------+
| > **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** |
+---------------------+-------------------------------------------+

+---------------------------+-----------------------------------------+
| **Authors/Contributors:** |                                         |
+===========================+=========================================+
| > **Paolo Badino**        | **European Organization for Nuclear     |
| >                         | Research (CERN), Switzerland**          |
| > **Olof Barring**        |                                         |
| >                         |                                         |
| > **Jean-Philippe Baud**  |                                         |
| >                         |                                         |
| > **Flavia Donno**        |                                         |
| >                         |                                         |
| > **Maarten Litmaath**    |                                         |
+---------------------------+-----------------------------------------+
| > **Timur Perelmutov**    | **Fermi National Accelerator Laboratory |
| >                         | (FNAL), USA**                           |
| > **Don Petravick**       |                                         |
+---------------------------+-----------------------------------------+
| > **Ezio Corso**          | **International Centre for Theoretical  |
| >                         | Physics (ICTO), Italy**                 |
| > **Luca Magnoni**        |                                         |
|                           | **Istituto Nazionale di Fisica Nucleare |
|                           | (INFN), Italy**                         |
+---------------------------+-----------------------------------------+
| > **Junmin Gu**           | **Lawrence Berkeley National Laboratory |
|                           | (LBNL), USA**                           |
+---------------------------+-----------------------------------------+
| > **Shaun De Witt**       | **Rutherford Appleton Laboratory (RAL), |
| >                         | England**                               |
| > **Jens Jensen**         |                                         |
+---------------------------+-----------------------------------------+
| > Michael Haddox-Schatz   | **Thomas Jefferson National Accelerator |
| >                         | Facility (TJNAF), USA**                 |
| > Bryan Hess              |                                         |
| >                         |                                         |
| > Andy Kowalski\          |                                         |
| > Chip Watson             |                                         |
+---------------------------+-----------------------------------------+

**Table of Contents**

[Abstract 5](#_Toc199734319)

[Introduction 5](#_Toc199734320)

[1. Common Type Definitions 7](#_Toc130102073)

[**1.1. Meaning of terms** 7](#_Toc188720107)

[**1.2. File Storage Type** 7](#_Toc188720109)

[**1.3. File Type** 8](#_Toc199734324)

[**1.4. Retention Policy** 8](#_Toc199734325)

[**1.5. Access Latency** 8](#_Toc199734326)

[**1.6. Permission Mode** 8](#_Toc199734327)

[**1.7. Permission Type** 9](#_Toc199734328)

[**1.8. Request Type** 9](#_Toc199734329)

[**1.9. Overwrite Mode** 9](#_Toc199734330)

[**1.10. File Locality** 9](#_Toc199734331)

[**1.11. Access Pattern** 10](#_Toc199734332)

[**1.12. Connection Type** 10](#_Toc199734333)

[**1.13. Status Codes** 10](#_Toc199734334)

[**1.14. Retention Policy Info** 11](#_Toc199734335)

[**1.15. Request Token** 11](#_Toc199734336)

[**1.16. User Permission** 11](#_Toc199734337)

[**1.17. Group Permission** 11](#_Toc199734338)

[**1.18. Size in Bytes** 11](#_Toc199734339)

[**1.19. UTC Time** 12](#_Toc199734340)

[**1.20. Time in Seconds (Lifetime and RequestTime)**
12](#_Toc199734341)

[**1.21. SURL** 12](#_Toc199734342)

[**1.22. TURL** 12](#_Toc199734343)

[**1.23. Return Status** 12](#_Toc199734344)

[**1.24. Return Status for SURL** 12](#_Toc199734345)

[**1.25. File MetaData** 13](#_Toc199734346)

[**1.26. Space MetaData** 13](#_Toc199734347)

[**1.27. Directory Option** 14](#_Toc199734348)

[**1.28. Extra Info** 14](#_Toc199734349)

[**1.29. Transfer Parameters** 14](#_Toc199734350)

[**1.30. File Request for srmPrepareToGet** 15](#_Toc199734351)

[**1.31. File Request for srmPrepareToPut** 15](#_Toc199734352)

[**1.32. File Request for srmCopy** 15](#_Toc199734353)

[**1.33. Return File Status for srmPrepareToGet** 15](#_Toc199734354)

[**1.34. Return File Status for srmBringOnline** 15](#_Toc199734355)

[**1.35. Return File Status for srmPrepareToPut** 15](#_Toc199734356)

[**1.36. Return File Status for srmCopy** 16](#_Toc199734357)

[**1.37. Request Summary** 16](#_Toc199734358)

[**1.38. Return Status for SURL** 16](#_Toc199734359)

[**1.39. Return File Permissions** 17](#_Toc199734360)

[**1.40. Return Permissions on SURL** 17](#_Toc199734361)

[**1.41. Return Request Tokens** 17](#_Toc199734362)

[**1.42. Supported File Transfer Protocol** 17](#_Toc199734363)

[2. Space Management Functions 18](#_Toc199734364)

[**2.1. srmReserveSpace** 18](#_Toc199734365)

[**2.2. srmStatusOfReserveSpaceRequest** 20](#_Toc199734366)

[**2.3. srmReleaseSpace** 21](#_Toc199734367)

[**2.4. srmUpdateSpace** 23](#_Toc199734368)

[**2.5. srmStatusOfUpdateSpaceRequest** 24](#_Toc58129358)

[**2.6. srmGetSpaceMetaData** 25](#_Toc199734370)

[**2.7. srmChangeSpaceForFiles** 26](#_Toc199734371)

[**2.8. srmStatusOfChangeSpaceForFilesRequest** 29](#_Toc199734372)

[**2.9. srmExtendFileLifeTimeInSpace** 31](#_Toc199734373)

[**2.10. srmPurgeFromSpace** 32](#_Toc199734374)

[**2.11. srmGetSpaceTokens** 34](#_Toc199734375)

[3. Permission Functions 36](#_Toc199734376)

[**3.1. srmSetPermission** 36](#_Toc199734377)

[**3.2. srmCheckPermission** 37](#_Toc199734378)

[**3.3. srmGetPermission** 38](#_Toc199734379)

[4. Directory Functions 40](#_Toc199734380)

[**4.1. srmMkdir** 40](#_Toc199734381)

[**4.2. srmRmdir** 40](#_Toc199734382)

[**4.3. srmRm** 41](#_Toc199734383)

[**4.4. srmLs** 43](#_Toc199734384)

[**4.5. srmStatusOfLsRequest** 45](#_Toc199734385)

[**4.6. srmMv** 47](#_Toc136425010)

[5. Data Transfer Functions 49](#_Toc199734387)

[**5.1. srmPrepareToGet** 49](#_Toc199734388)

[**5.2. srmStatusOfGetRequest** 52](#_Toc199734389)

[**5.3. srmBringOnline** 55](#_Toc199734390)

[**5.4. srmStatusOfBringOnlineRequest** 59](#_Toc199734391)

[**5.5. srmPrepareToPut** 61](#_Toc199734392)

[**5.6. srmStatusOfPutRequest** 65](#_Toc199734393)

[**5.7. srmCopy** 68](#_Toc199734394)

[**5.8. srmStatusOfCopyRequest** 72](#_Toc199734395)

[**5.9. srmReleaseFiles** 75](#_Toc199734396)

[**5.10. srmPutDone** 77](#_Toc199734397)

[**5.11. srmAbortRequest** 78](#_Toc199734398)

[**5.12. srmAbortFiles** 80](#_Toc199734399)

[**5.13. srmSuspendRequest** 81](#_Toc199734400)

[**5.14. srmResumeRequest** 82](#_Toc199734401)

[**5.15. srmGetRequestSummary** 82](#_Toc199734402)

[**5.16. srmExtendFileLifeTime** 84](#_Toc199734403)

[**5.17. srmGetRequestTokens** 86](#_Toc199734404)

[6. Discovery Functions 87](#_Toc199734405)

[**6.1. srmGetTransferProtocols** 87](#_Toc199734406)

[**6.2. srmPing** 87](#_Toc188720194)

[7. Storage Resource Managers Concepts 89](#_Toc199734408)

[**7.1. Summary** 89](#_Toc199734409)

[**7.2. Overview** 89](#_Toc199734410)

[**7.3. The Basic Concepts** 90](#_Toc199734411)

[**7.4. Additional concepts introduced with v2.2** 92](#_Toc199734412)

[**7.5. SRM Implementations** 94](#_Toc199734413)

[8. Appendix I : Current SRM Implementations Based on v2.2 specification
96](#_Toc199734414)

[**8.1. BeStMan -- Berkeley Storage Manager** 96](#_Toc199734415)

[**8.2. Castor-SRM** 96](#_Toc199734416)

[**8.3. dCache-SRM** 97](#_Toc199734417)

[**8.4. DPM -- Disk Pool Manager** 97](#_Toc199734418)

[**8.5. StoRM - Storage Resource Manager** 97](#_Toc199734419)

[9. Appendix II : WLCG use case 97](#_Toc199734420)

[**Introduction** 97](#_Toc199734421)

[**9.1. Storage classes** 98](#_Toc199734422)

[**9.2. Removal policies** 99](#_Toc199734423)

[**9.3. Protocol negotiation** 99](#_Toc199734424)

[**9.4. Information discovery** 99](#_Toc199734425)

[**9.5. srmReserveSpace** 99](#_Toc199734426)

[**9.6. srmChangeSpaceForFiles** 99](#_Toc199734427)

[**9.7. srmPurgeFromSpace** 100](#_Toc199734428)

[**9.8. srmRm** 100](#_Toc199734429)

[**9.9. srmLs** 100](#_Toc199734430)

[**9.10. srmPrepareToGet** 101](#_Toc199734431)

[**9.11. srmBringOnline** 101](#_Toc199734432)

[**9.12. srmPrepareToPut** 102](#_Toc199734433)

[**9.13. srmCopy** 102](#_Toc199734434)

[10. Contributors 103](#_Toc199734435)

[11. Acknowledgement 103](#_Toc199734436)

[12. Copyright Notice 103](#_Toc199734437)

[13. OGF Disclaimer 104](#_Toc199734438)

[14. OGF Intellectual Property Statement 104](#_Toc199734439)

[15. OGF Copyright Notice 104](#_Toc199734440)

[16. References 104](#_Toc199734441)

***\
***[]{#_Toc199734319 .anchor}**Abstract**

Storage management is one of the most important enabling technologies
for large-scale scientific investigations. Having to deal with multiple
heterogeneous storage and file systems is one of the major bottlenecks
in managing, replicating, and accessing files in distributed
environments. Storage Resource Managers (SRMs), named after their web
services protocol, provide the technology needed to manage the rapidly
growing distributed data volumes, as a result of faster and larger
computational facilities. SRMs are Grid storage services providing
interfaces to storage resources, as well as advanced functionality such
as dynamic space allocation and file management on shared storage
systems. They call on transport services to bring files into their space
transparently and provide effective sharing of files. SRMs are based on
a common specification that emerged over time and evolved into an
international collaboration. This approach of an open specification that
can be used by various institutions to adapt to their own storage
systems has proven to be a remarkable success -- the challenge has been
to provide a consistent homogeneous interface to the Grid, while
allowing sites to have diverse infrastructures. In particular, one of
the main goals to the SRM web service is to support optional features
while preserving interoperability.

[]{#_Toc199734320 .anchor}**Introduction**

This document contains the concepts and 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 at Fermilab, which followed by a 3-day meeting in
September 2006 at CERN. Since that time several smaller meetings have
taken place as well as email correspondence and conference calls. The
purpose of this activity is to agree on the functionality and
standardize the interface of Storage Resource Managers (SRMs) -- a Grid
middleware component.

This document reflects the current status of the specification, which
has been frozen in order to allow multiple implementations to proceed.

The document is organized in seven sections. The first describes the
main concepts of SRMs as a standard middleware specification for various
storage systems. It is intended to support the same interface to simple
files systems, as well as sophisticated storage system that include
multiple disk caches, robotic tape systems, and parallel file
systems.The second, called "Common Type Definitions" contains 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.

Appendix I lists several implementations of SRM v2.2 around the world,
and their deployment in various sites.

As can be expected, when a large collaboration decide to use the SRM
specification, it may choose to restrict some of the functionality
according to their common projects requirements. For example, some
collaboration may choose to restrict space reservations to
administrators only, and not permit dynamic reservations by other users.
Similarly, the collaboration may choose to support only permanent
storage files, rather than allow automatic removal of files whose
lifetime has expired by the SRM.

An interesting and influential collaboration is described in Appendix
II. The collaboration is in the High Energy Physics domain, and it
purpose is to develop the tools to managed the petabytes of data
expected from the Large Hadron Collider (LHC). The collaboration, called
Worldwide LHC Computing Grid (WLCG) project, involves implementing
Storage Resource Managers on top of various storage systems based on the
SRM v2.2 specification described here. Appendix II described the
restrictions and behaviors the WLCG project has chosen in order to
achieve interoperability of all SRM implementations under a tight time
schedule. It is important to note that the WLCG collaboration also added
enhancement in terms of functionality and clarity of the specification,
an invaluable contribution based on practical requirements.

For people not familiar with SRM concepts, it is advisable to read the
first chapter. For people familiar with previous versions of SRM
specifications, it is advisable to read the document
SRM.v2.2.changes.doc posted at http://sdm.lbl.gov/srm-wg before reading
this specification.Another SRM-related activity that was recently
published is to provide a formal conceptual model of the SRM behavior
\[ISGC2007\].

This document is modified from OGF.129 for more readability towards
funcional interfaces. OGF.129 document fixes many typos and includes
some clarifications from the previous version (2 April 2007).

1.  []{#_Toc130102073 .anchor}***Common Type Definitions***

**Namespace[SRM]{.underline}**

1.  []{#_Toc188720107 .anchor}**Meaning of terms**

```{=html}
<!-- -->
```
a)  **[Underlined]{.underline}**attributes are ***REQUIRED*. The
    required attributes must be parsed correctly and must give proper
    error messages when not supported.**

b)  By "https" we mean [http]{.underline} protocol with
    [GSI]{.underline} 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.

c)  Primitive types used below are consistent with XML build-in schema
    types**:** i.e.

    -   *[long]{.underline}*is 64bit: **(+/-)** 9223372036854775807

    -   *[int]{.underline}*is 32 bit**: (+/-)** 2147483647

    -   *[short]{.underline}*is 16 bit**: (+/-)** 32767

    -   *[unsignedLong]{.underline}*ranges (inclusive): 0
        to18446744073709551615

    -   *[unsignedInt]{.underline}* ranges (inclusive): 0 to 4294967295

    -   *[unsignedShort]{.underline}* ranges (inclusive):0 to 65535

d)  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\]\".

e)  In "localSURL", we mean local to the SRM that is processing the
    request.

f)  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.

g)  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.

h)  The word "pinning" is limited to the "copies" or "states" of SURLs
    and the Transfer URLs (TURLs).

i)  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.  []{#_Toc188720109 .anchor}**File Storage Type**

enum **TFileStorageType** {VOLATILE, DURABLE, PERMANENT}

-   Volatile file has a lifetime and the storage may delete all traces
    of the file when it expires.

-   Permanent file has no expiration time.

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

2.  []{#_Toc199734324 .anchor}**File Type**

enum **TFileType** {FILE, DIRECTORY, LINK}

3.  []{#_Toc199734325 .anchor}**Retention Policy**

enum **TRetentionPolicy** { REPLICA , OUTPUT , CUSTODIAL }

-   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.

```{=html}
<!-- -->
```
-   The type is 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 is 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 through the TMetaDataPathDetail structure returned by the
    srmLs function.

4.  []{#_Toc199734326 .anchor}**Access Latency**

enum **TAccessLatency** { ONLINE, NEARLINE }

-   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.

-   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.

-   For the SRM, ONLINE and NEARLINE are specified, and files may be
    ONLINE and/or NEARLINE.

5.  []{#_Toc199734327 .anchor}**Permission Mode**

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

6.  []{#_Toc199734328 .anchor}**Permission Type**

enum **TPermissionType** {ADD, REMOVE, CHANGE}

7.  []{#_Toc199734329 .anchor}**Request Type**

enum **TRequestType** { PREPARE\_TO\_GET,

PREPARE\_TO\_PUT,

COPY,

BRING\_ONLINE,

RESERVE\_SPACE,

UPDATE\_SPACE,

CHANGE\_SPACE\_FOR\_FILES,

> LS}

8.  []{#_Toc199734330 .anchor}**Overwrite Mode**

enum **TOverwriteMode** {NEVER,

> ALWAYS,
>
> WHEN\_FILES\_ARE\_DIFFERENT}

-   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.

-   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.

9.  []{#_Toc199734331 .anchor}**File Locality**

enum **TFileLocality**{ ONLINE,

> NEARLINE,
>
> ONLINE\_AND\_NEARLINE,
>
> LOST,
>
> NONE.
>
> UNAVAILABLE }

-   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.

-   The type is used to describe a file property that indicates the
    current location or status in the storage system.

10. []{#_Toc199734332 .anchor}**Access Pattern**

enum **TAccessPattern** { TRANSFER\_MODE, PROCESSING\_MODE }

-   TAccessPattern may be passed as an input parameter to the
    srmPrepareToGet and srmBringOnline functions. It provides 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 allows 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.

11. []{#_Toc199734333 .anchor}**Connection Type**

enum **TConnectionType** { WAN, LAN }

-   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 input
    parameter may be passed to the srmPrepareToGet, srmPrepareToPut and
    srmBringOnline functions.

12. []{#_Toc199734334 .anchor}**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
>
> }

-   SRM\_NOT\_SUPPORTED must be used, in general

    -   If a server does not support a method

    -   If a server does not support particular optional input
        parameters

13. []{#_Toc199734335 .anchor}**Retention Policy Info**

typedef struct { TRetentionPolicy [retentionPolicy]{.underline},

TAccessLatency accessLatency

} **TRetentionPolicyInfo**

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

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

14. []{#_Toc199734336 .anchor}**Request Token**

-   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 can be immutable.

-   Request tokens are case-sensitive.

-   Request token is valid until the request is completed. However, SRM
    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.

15. []{#_Toc199734337 .anchor}**User Permission**

typedef struct { string [userID]{.underline},

TPermissionMode [mode]{.underline}

> } **TUserPermission**

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

16. []{#_Toc199734338 .anchor}**Group Permission**

typedef struct { string [groupID]{.underline},

TPermissionMode [mode]{.underline}

> } **TGroupPermission**

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

17. []{#_Toc199734339 .anchor}**Size in Bytes**

-   Size in bytes is represented in unsigned long.

18. []{#_Toc199734340 .anchor}**UTC Time**

-   **Time is represented in dateTime.**

-   Formerly TGMTTime in SRM v2.1

-   date and time in Coordinated Universal Time (UTC, formerly GMT) with
    no local time extention.

-   *Format is same as in XML dateTime type \[XSDDATE\], except no local
    time extension is allowed. E.g.* 1999-05-31T13:20:00 is ok (for 1999
    May 31st, 13:20PM, UTC) but 1999-05-31T13:20:00-5:00 is not.

19. []{#_Toc199734341 .anchor}**Time in Seconds (Lifetime and
    RequestTime)**

-   **Time (lifetime and request time) in seconds is represented in
    integer.**

-   "0" (zero) indicates the site defined default time.

-   A negative value (-1) indicates "infinite (indefinite)" time.

-   Exceptions:

    -   Any "remaining" times must have zero (0) second when no lifetime
        is left.

    -   Some special meaning of negative time is defined when needed
        depending on the operation. E.g. remainingTotalRequestTime in
        srmStatusOfGetRequest

20. []{#_Toc199734342 .anchor}**SURL**

-   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.

21. []{#_Toc199734343 .anchor}**TURL**

-   **TURL is represented in anyURI.**

22. []{#_Toc199734344 .anchor}**Return Status**

typedef struct {TStatusCode [statusCode]{.underline},

string explanation

> } **TReturnStatus**

23. []{#_Toc199734345 .anchor}**Return Status for SURL**

typedef struct {anyURI [surl]{.underline},

TReturnStatus [status]{.underline}

> } **TSURLReturnStatus**

24. []{#_Toc199734346 .anchor}**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**

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

-   *retentionPolicyInfo* indicates the assigned retention policy.

-   *fileLocality* indicates where the file is located currently in the
    system.

-   *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.

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

-   *ownerPermission* describes the owner ID and owner permission on the
    SURL.

-   *groupPermission* describes the group permission with group
    identifier on the SURL.

-   *otherPermission* describes the other permission on the SURL.

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

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

-   *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.

25. []{#_Toc199734347 .anchor}**Space MetaData**

typedef struct { string [spaceToken]{.underline},

**TReturnStatus** status,

TRetentionPolicyInfo retentionPolicyInfo,

> string owner,

**unsigned long** totalSize, // best effort

> **unsigned long** guaranteedSize,
>
> **unsigned long** unusedSize,

int lifetimeAssigned,

int lifetimeLeft

> } **TMetaDataSpace**

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

-   *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*.

-   *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.

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

-   *lifetimeLeft* is the remaining lifetime that is left on the space.

26. []{#_Toc199734348 .anchor}**Directory Option**

typedef struct { boolean [isSourceADirectory]{.underline},

boolean allLevelRecursive, // default = false

int numOfLevels // default = 1

> } **TDirOption**

27. []{#_Toc199734349 .anchor}**Extra Info**

typedef struct { string [key]{.underline},

string value

> } **TExtraInfo**

-   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.

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

28. []{#_Toc199734350 .anchor}**Transfer Parameters**

typedef struct { TAccessPattern accessPattern,

TConnectionType connectionType,

string\[\] arrayOfClientNetworks,

string\[\] arrayOfTransferProtocols

> } **TTransferParameters**

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

-   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.

-   File transfer protocols must be specified in a preferred order on
    all SRM transfer functions.

-   arrayOfClientNetworks provides a hint of the client IPs that
    SRM/dCache may use for optimization of its internal storage systems
    based on the client's accessible IP addresses.

29. []{#_Toc199734351 .anchor}**File Request for srmPrepareToGet**

typedef struct { anyURI [sourceSURL]{.underline},

> TDirOption dirOption
>
> } **TGetFileRequest**

30. []{#_Toc199734352 .anchor}**File Request for srmPrepareToPut**

typedef struct { anyURI targetSURL, // local to SRM

unsigned long expectedFileSize

> } **TPutFileRequest**

31. []{#_Toc199734353 .anchor}**File Request for srmCopy**

typedef struct { anyURI [sourceSURL]{.underline},

anyURI [targetSURL]{.underline},

> TDirOption dirOption
>
> } **TCopyFileRequest**

32. []{#_Toc199734354 .anchor}**Return File Status for srmPrepareToGet**

typedef struct {anyURI [sourceSURL]{.underline},

TReturnStatus [status]{.underline},

unsigned long [fileSize]{.underline},

int estimatedWaitTime,

> int remainingPinTime,
>
> anyURI transferURL,
>
> TExtraInfo\[\] transferProtocolInfo
>
> } **TGetRequestFileStatus**

-   *transferProtocolInfo* of type *TExtraInfo* can provide more
    information about the transfer protocol so that client can access
    the TURL efficiently.

-   *estimatedWaitTime must be negative value, -1, for unknown.*

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

33. []{#_Toc199734355 .anchor}**Return File Status for srmBringOnline**

typedef struct {anyURI [sourceSURL]{.underline},

TReturnStatus [status]{.underline},

unsigned long [fileSize]{.underline},

int estimatedWaitTime,

> int remainingPinTime
>
> } **TBringOnlineRequestFileStatus**

-   *estimatedWaitTime must be negative value, -1, for unknown.*

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

34. []{#_Toc199734356 .anchor}**Return File Status for srmPrepareToPut**

typedef struct { anyURI [SURL]{.underline},

TReturnStatus [status]{.underline},

> unsigned long [fileSize]{.underline},

int estimatedWaitTime,

> int remainingPinLifetime, // on TURL
>
> int remainingFileLifetime, // on SURL
>
> anyURI transferURL,

TExtraInfo\[\] transferProtocolInfo

> } **TPutRequestFileStatus**

-   *transferProtocolInfo* of type *TExtraInfo*can provide 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.

-   *estimatedWaitTime must be negative value, -1, for unknown.*

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

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

35. []{#_Toc199734357 .anchor}**Return File Status for srmCopy**

typedef struct {anyURI [sourceSURL]{.underline},

anyURI [targetSURL]{.underline},

TReturnStatus [status]{.underline},

unsigned long [fileSize]{.underline},

int estimatedWaitTime,

> int remainingFileLifetime // on target SURL
>
> } **TCopyRequestFileStatus**

-   *estimatedWaitTime must be negative value, -1, for unknown.*

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

36. []{#_Toc199734358 .anchor}**Request Summary**

typedef struct {string [requestToken]{.underline},

TReturnStatus [status]{.underline},

TRequestType requestType,

int totalNumFilesInRequest,

int numOfCompletedFiles,

int numOfWaitingFiles,

int numOfFailedFiles

> } **TRequestSummary**

-   *numOfWaitingFiles* describes the number of files on the queue.

-   *numOfFailedFiles* describes the number of failed files and aborted
    files.

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

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

37. []{#_Toc199734359 .anchor}**Return Status for SURL**

typedef struct { anyURI [surl]{.underline},

TReturnStatus [status]{.underline},

int fileLifetime,

int pinLifetime,

> } **TSURLLifetimeReturnStatus**

-   *fileLifetime* describes the file lifetime on SURL.

-   *pinLifetime* describes the pin lifetime on TURL, if applicable.

38. []{#_Toc199734360 .anchor}**Return File Permissions**

typedef struct {anyURI [surl]{.underline},

TReturnStatus [status]{.underline},

TPermissionMode permission

> } **TSURLPermissionReturn**

39. []{#_Toc199734361 .anchor}**Return Permissions on SURL**

typedef struct {anyURI [surl]{.underline}, // both dir and file

**TReturnStatus** status,

string owner,

TPermissionMode ownerPermission,

> TUserPermission\[\] arrayOfUserPermissions,
>
> TGroupPermission\[\] arrayOfGroupPermissions,
>
> TPermissionMode otherPermission
>
> } **TPermissionReturn**

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

40. []{#_Toc199734362 .anchor}**Return Request Tokens**

typedef struct { string [requestToken]{.underline},

dateTime createdAtTime

> } **TRequestTokenReturn**

41. []{#_Toc199734363 .anchor}**Supported File Transfer Protocol**

typedef struct {**string [transferProtocol]{.underline}**,

**TExtraInfo\[\] attributes**

> } **TSupportedTransferProtocol**

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

```{=html}
<!-- -->
```
-   *attributes:*Informational hints for the paired transfer protocol,
    ***such how many number of parallel streams can be used, desired
    buffer size, etc***.

2.  **\
    **[]{#_Toc199734364 .anchor}**Space Management *Functions***

***summary:***

[**srmReserveSpace**](#_Toc199734365)

[**srmStatusOfReserveSpaceRequest**](#_Toc199734366)

[**srmReleaseSpace**](#_Toc199734367)

[**srmUpdateSpace**](#_Toc199734368)

[**srmGetSpaceMetaData**](#_Toc199734370)

[**srmChangeSpaceForFiles**](\l)

[**srmStatusOfChangeSpaceForFilesRequest**](\l)

[**srmExtendFileLifeTimeInSpace**](\l)

[**srmPurgeFromSpace**](\l)

[**srmGetSpaceTokens**](\l)

1.  []{#_Toc199734365 .anchor}**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.

1.  **Parameters**

In: string authorizationID,

> string userSpaceTokenDescription,

TRetentionPolicyInfo [retentionPolicyInfo]{.underline},

> **unsigned long** desiredSizeOfTotalSpace,
>
> **unsigned long** [desiredSizeOfGuaranteedSpace]{.underline},
>
> int desiredLifetimeOfReservedSpace,
>
> **unsigned long \[\] arrayOfExpectedFileSizes,**
>
> TExtraInfo\[\] storageSystemInfo,
>
> TTransferParameters transferParameters

Out: TReturnStatus [returnStatus]{.underline},

> string requestToken,

int estimatedProcessingTime,

TRetentionPolicyInfo retentionPolicyInfo,

> **unsigned long** sizeOfTotalReservedSpace, // best effort
>
> **unsigned long** sizeOfGuaranteedReservedSpace,
>
> int lifetimeOfReservedSpace,
>
> string spaceToken

2.  **Notes on the Behavior**

```{=html}
<!-- -->
```
a)  *Input parameter userSpaceTokenDescription* is case-sensitive. SRM
    is expected to keep it as client provides. It can be reused by the
    client. *srmGetSpaceTokens*must return all the space tokens that
    have the same *userSpaceTokenDescription.*

b)  If the input parameter *desiredLifetimeOfReservedSpace* is not
    provided, the lifetime of the reserved space may be set to "infinite
    (indefinite)" by default, if indefinite lifetime on space is
    supported by the implementation and local policy.

c)  If particular values of the input parameter *retentionPolicyInfo*
    cannot be satisfied by the SRM, 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 must be SRM\_REQUEST\_QUEUED.

f)  **Input parameter *arrayOfExpectedFileSize*provides a hint that SRM
    may 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
    providesinformation on 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 access information.

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

i)  If input parameter *desiredSizeOfTotalSpace* is not specified, the
    SRM may 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*must be returned 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.

    1.  **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

-   **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 fails 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.

-   **Some input parameters are invalid.**

> **SRM\_NO\_USER\_SPACE**

-   **SRM does not have enough user space for the client to reserve.**

> **SRM\_NO\_FREE\_SPACE**

-   **SRM does not have enough free space for client to reserve.**

-   **SRM does not have enough free space for the requested
    > retentionPolicyInfo to reserve**

> **SRM\_EXCEED\_ALLOCATION**

-   **SRM does not have enough space for the request because the client
    > requests 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**

```{=html}
<!-- -->
```
-   specific values of the input parameter *retentionPolicyInfo* is not
    supported by the SRM

```{=html}
<!-- -->
```
-   **a specified input parameter is not supported in the SRM**

    1.  []{#_Toc199734366 .anchor}**srmStatusOfReserveSpaceRequest**

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

1.  **Parameters**

In: string authorizationID,

string [requestToken]{.underline}

Out: TReturnStatus [returnStatus]{.underline},

> int estimatedProcessingTime,

TRetentionPolicyInfo retentionPolicyInfo,

> **unsigned long** sizeOfTotalReservedSpace,
>
> **unsigned long** sizeOfGuaranteedReservedSpace,
>
> int lifetimeOfReservedSpace,
>
> string spaceToken

2.  **Notes on the Behavior**

```{=html}
<!-- -->
```
a)  If the space reservation is not completed yet,
    *estimateProcessingTime*may be 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*must be returned to the
    client.

    1.  **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 fails 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.**

> SRM\_EXCEED\_ALLOCATION

-   **SRM does not have enough space for the request because the client
    > requestsmore than the allocated space for the client.**

> **SRM\_NO\_USER\_SPACE**

-   **SRM does not have enough user space for the client to reserve.**

> **SRM\_NO\_FREE\_SPACE**

-   **SRM does not have enough free space for the client to reserve.**

-   **SRM does not have enough free space for a particular
    > retentionPolicyInfo to reserve**

> **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**

-   **a specified input parameter is not supported in the SRM**

    1.  []{#_Toc199734367 .anchor}**srmReleaseSpace**

**srmReleaseSpace() releases an occupied space.**

1.  **Parameters**

In: string authorizationID,

> string [spaceToken]{.underline},
>
> TExtraInfo\[\] storageSystemInfo,

boolean forceFileRelease

> Out: TReturnStatus [returnStatus]{.underline}

2.  **Notes on the Behavior**

```{=html}
<!-- -->
```
a)  *Inputparameter forceFileRelease*must be 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 must be 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, those files are released 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 must be
    removed and SRM\_INVALID\_PATH must be returned by the srmPutDone,
    srmStatusOfPutRequest, or srmStatusOfCopyRequest when the file is
    volatile. If the file has permanent type, the file may be moved to
    the space that SRM manages, and the space would be successfully
    released. The subsequent srmPutDone, srmStatusOfPutRequest, or
    srmStatusOfCopyRequestmust 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.*

    1.  **Return Status Code**

> **SRM\_SUCCESS**

-   **successful request completion. Space is successfully released.**

> **SRM\_AUTHENTICATION\_FAILURE**

-   **SRM fails 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.**

> **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 token is already released.**

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

    1.  []{#_Toc199734368 .anchor}**srmUpdateSpace**

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

1.  **Parameters**

In: string authorizationID,

> string [spaceToken]{.underline},
>
> **unsigned long** newSizeOfTotalSpaceDesired,
>
> **unsigned long** newSizeOfGuaranteedSpaceDesired,
>
> int newLifeTime,
>
> TExtraInfo\[\] storageSystemInfo

Out: TReturnStatus [returnStatus]{.underline},

> string requestToken,
>
> **unsigned long** sizeOfTotalSpace, // best effort
>
> **unsigned long** sizeOfGuaranteedSpace,
>
> int lifetimeGranted

2.  **Notes on the Behavior**

```{=html}
<!-- -->
```
a)  If neither size nor lifetime is provided in the input parameters,
    then the request must 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 may even be shorter than the remaining
    lifetime at the time of the call. It is relative to the calling
    time. Lifetime must 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 may even be shorter than the
    previous lifetime. It is relative to the calling time.

    1.  **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 fails 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.**

-   **input parameter size or lifetime is not provided.**

> SRM\_EXCEED\_ALLOCATION

-   **SRM does not have enough space for the request because the client
    > requests more than the allocated space for the client.**

> **SRM\_NO\_USER\_SPACE**

-   **SRM does not have enough user space for the client request**

> **SRM\_NO\_FREE\_SPACE**

-   **SRM does not have enough free space for 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 occupied space.**

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

> **SRM\_NOT\_SUPPORTED**

-   ***function* is not supported**

[]{#_Toc58129358 .anchor}

1.  **srmStatusOfUpdateSpaceRequest**

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

1.  **Parameters**

In: string authorizationID,

> string [requestToken]{.underline}

Out: TReturnStatus [returnStatus]{.underline},

> **unsigned long** sizeOfTotalSpace, // best effort
>
> **unsigned long** sizeOfGuaranteedSpace,
>
> int lifetimeGranted

2.  **Notes on the Behavior**

```{=html}
<!-- -->
```
a)  Output parameters for new sizes are the new actual sizes of the
    space.

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

    1.  **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 fails 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.**

-   **input parameter size or time is not provided.**

> SRM\_EXCEED\_ALLOCATION

-   **SRM does not have enough space for the request because the client
    > requests more than the allocated space for the client.**

> **SRM\_NO\_USER\_SPACE**

-   **SRM does not have enough user space for the client request**

> **SRM\_NO\_FREE\_SPACE**

-   **SRM does not have enough free space for 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 occupied space.**

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

> **SRM\_NOT\_SUPPORTED**

-   ***function* is not supported**

    1.  []{#_Toc199734370 .anchor}**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 previous
space reservation through *srmReserveSpace* or
*srmStatusOfReserveSpaceRequest*.

1.  **Parameters**

In: string authorizationID,

> string\[\] [arrayOfSpaceTokens]{.underline}

Out: TReturnStatus [returnStatus]{.underline},

> TMetaDataSpace\[\] arrayOfSpaceDetails

2.  **Notes on the Behavior**

```{=html}
<!-- -->
```
a)  Output parameters *unusedSize* in *TMetaDataSpace*must be 0 if there
    is no space left in the allocated space.

    1.  **Return Status Code**

**For request level return Status,**

> **SRM\_SUCCESS**

-   **successful request completion. Information of all requested spaces
    isreturned 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 fails 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 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**

**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.**

> **SRM\_SPACE\_LIFETIME\_EXPIRED**

-   **The lifetime on the space that is associated with the *spaceToken*
    has expired already**

> **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.**

    1.  []{#_Toc199734371 .anchor}**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 must be
returned for later status request. There is no default behavior when
target space token is not provided. In such case, the request must be
failed, and the return status must be SRM\_INVALID\_REQUEST.

1.  **Parameters**

In: string authorizationID,

anyURI \[\] [arrayOfSURLs]{.underline},

string [targetSpaceToken]{.underline},

TExtraInfo\[\] storageSystemInfo

Out: TReturnStatus [returnStatus]{.underline},

> string requestToken,

int estimatedProcessingTime,

TSURLReturnStatus \[\] arrayOfFileStatuses

2.  **Notes on the Behavior**

```{=html}
<!-- -->
```
a)  When space transition is completed successfully, SRM\_SUCCESS must
    be returned for each SURL.

b)  For any forbidden transition, SRM\_INVALID\_REQUEST must be
    returned. It includes changing spaces on SURLs that their statuses
    are SRM\_FILE\_BUSY.

c)  Asynchronous operation may be necessary for some SRMs. 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
    must be SRM\_REQUEST\_QUEUED, and *arrayOfFileStatuses* may not be
    filled and returned.

e)  All files specified in *arrayOfSURLs* will be associated with the
    new space specified by *targetSpaceToken.*

f)  Space allocation for a new target 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.

i)  When a space is successfully changed for a file from one space to
    another, the file must retain its remaining lifetime, or the file
    lifetime must 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.

    1.  **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 fails 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.**

-   ***targetSpaceToken* refers to a** forbidden transition by the
    SRM**.**

> **SRM\_SPACE\_LIFETIME\_EXPIRED**

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

> **SRM\_EXCEED\_ALLOCATION**

-   ***targetspace 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**

-   **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**

-   **a specified input parameter is not supported in the SRM**

**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**.**

-   **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 a file which there is an active srmPrepareToPut
    (no srmPutDone is yet called) request 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**

-   **file request is failed.**

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

    1.  []{#_Toc199734372
        .anchor}**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*.

1.  **Parameters**

In: string authorizationID,

string [requestToken]{.underline}

Out: TReturnStatus [returnStatus]{.underline},

> int estimatedProcessingTime,
>
> TSURLReturnStatus \[\] arrayOfFileStatuses

2.  **Notes on the Behavior**

```{=html}
<!-- -->
```
a)  When space transition is completed successfully, SRM\_SUCCESS must
    be returned for each SURL.

b)  If changing space is not completed, *estimateProcessingTime*may be
    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 must 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 must 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.

    1.  **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 is 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 fails 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.**

-   ***targetSpaceToken* refers to a** forbidden transition by the
    SRM**.**

> **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
    large 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**

-   **a specified input parameter is not supported in the SRM**

**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

-   **The status of SURL is SRM\_FILE\_BUSY.**

> **SRM\_EXCEED\_ALLOCATION**

-   ***target space that is associated with targetSpaceToken* is not
    large 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 a file which there is an active srmPrepareToPut
    (no srmPutDone is yet called) request 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**

-   **file request is failed.**

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

    1.  []{#_Toc199734373 .anchor}**srmExtendFileLifeTimeInSpace**

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

1.  **Parameters**

In: string authorizationID,

> string spaceToken,

anyURI\[\] arrayOfSURLs,

int newLifeTime

Out: TReturnStatus [returnStatus]{.underline},

TSURLLifetimeReturnStatus \[\] arrayOfFileStatuses

2.  **Notes on the Behavior**

```{=html}
<!-- -->
```
a)  *arrayOfSURLs*is optional. When SURLs are not provided, all files in
    the space must have the new extended lifetime.

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 must not change the
    lifetime.

g)  If input parameter *newLifeTime* exceeds 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.

    1.  **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 fails 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.**

> **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**

-   **a specified input parameter is not supported in the SRM**

**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.**

    1.  []{#_Toc199734374 .anchor}**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.

1.  **Parameters**

In: string authorizationID,

anyURI \[\] [arrayOfSURLs]{.underline},

string [spaceToken]{.underline},

TExtraInfo\[\] storageSystemInfo

Out: TReturnStatus [returnStatus]{.underline},

> TSURLReturnStatus\[\] arrayOfFileStatuses

2.  **Notes on the Behavior**

```{=html}
<!-- -->
```
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*must be used.

b)  If the client has an administrative role that SRM can accept in an
    understandable form, the request must 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 must be returned.

d)  SRM must remove only the "copies" (or "state") of the *SURLs*
    associated with the space token.

    1.  **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 fails 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 a file which there is an active srmPrepareToPut
    (no srmPutDone is yet called) request 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.**

    1.  []{#_Toc199734375 .anchor}**srmGetSpaceTokens**

**srmGetSpaceTokens() returns space tokens for currently allocated
spaces for the client.**

1.  **Parameters**

In: string userSpaceTokenDescription,

string authorizationID

Out: TReturnStatus [returnStatus]{.underline},

> string\[\] arrayOfSpaceTokens

2.  **Notes on the Behavior**

```{=html}
<!-- -->
```
a)  If *userSpaceTokenDescription* is null, returns all space tokens
    theclient owns.

b)  *Optional input parameter userSpaceTokenDescription* is
    case-sensitive. SRM is expected to keep it as client provides. It
    may be reused by the client. *srmGetSpaceTokens*must return all the
    space tokens that have the*userSpaceTokenDescription.*

c)  If a client assigns the same descriptionin multiple space
    reservations, the client may get back multiple space tokens.

    1.  **Return Status Code**

> **SRM\_SUCCESS**

-   **All requests are successfully completed. Space tokens are returned
    successfully.**

> **SRM\_AUTHENTICATION\_FAILURE**

-   **SRM fails 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**

3.  **\
    **[]{#_Toc199734376 .anchor}**Permission *Functions***

***summary:***

> [**srmSetPermission**](#_Toc199734377)
>
> [**srmCheckPermission**](#_Toc199734378)
>
> [**srmGetPermission**](#_Toc199734379)

1.  []{#_Toc199734377 .anchor}**srmSetPermission**

srmSetPermission is to set permission on local SURL.

1.  **Parameters**

In: string authorizationID,

> anyURI [SURL]{.underline},
>
> TPermissionType [permissionType]{.underline},
>
> TPermissionMode ownerPermission,
>
> TUserPermission\[\] arrayOfUserPermissions,
>
> TGroupPermission\[\] arrayOfGroupPermissions,
>
> TPermissionMode otherPermission,

TExtraInfo\[\] storageSystemInfo

Out: TReturnStatus [returnStatus]{.underline}

2.  **Notes on the Behavior**

```{=html}
<!-- -->
```
a)  Applies to both directories and files.

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 must be assumed that *TPermissionMode* is READ only.

h)  If *TPermissionType* is REMOVE, then the *TPermissionMode*must be
    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 must work 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 user or group, the specified permissions must replace the
    current permissions. If an entry does not exist for the specified
    user or group, an entry must be created.

j)  *srmSetPermission must modify permissions on SURLs even if the
    statuses of the SURLs are SRM\_FILE\_BUSY.*

    1.  **Return Status Code**

> **SRM\_SUCCESS**

-   **successful request completion. *SURL* has a new permission.**

> **SRM\_AUTHENTICATION\_FAILURE**

-   **SRM fails 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**

-   **a specified input parameter is not supported in the SRM**

    1.  []{#_Toc199734378 .anchor}**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.***

1.  **Parameters**

In: anyURI \[\] [arrayOfSURLs]{.underline},

string authorizationID,

TExtraInfo\[\] storageSystemInfo

Out: TReturnStatus [returnStatus]{.underline},

> **TSURLPermissionReturn**\[\] arrayOfPermissions

2.  **Notes on the Behavior**

```{=html}
<!-- -->
```
a)  SRM checks files in its local online and nearline storage when
    supported.

    1.  **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 fails 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.**

    1.  []{#_Toc199734379 .anchor}**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.***

1.  **Parameters**

In: anyURI \[\] [arrayOfSURLs]{.underline},

string authorizationID,

TExtraInfo\[\] storageSystemInfo

Out: TReturnStatus [returnStatus]{.underline},

> **TPermissionReturn**\[\] arrayOfPermissionReturns

2.  **Notes on the Behavior**

```{=html}
<!-- -->
```
b)  SRM checks files in its local online and nearline storage when
    supported.

    1.  **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 fails 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.  **\
    **[]{#_Toc199734380 .anchor}**Directory *Functions***

***summary:***

> [**srmMkdir**](#_Toc199734381)
>
> [**srmRmdir**](#_Toc199734382)
>
> [**srmRm**](#_Toc199734383)
>
> [**srmLs**](#srmLs)
>
> [**srmStatusOfLsRequest**](#_Toc199734385)

[**srmMv**](\l)

1.  []{#_Toc199734381 .anchor}**srmMkdir**

srmMkdir creates a directory in local SRM.

1.  **Parameters**

In: string authorizationID,

> anyURI [SURL]{.underline},

TExtraInfo\[\] storageSystemInfo

> Out: TReturnStatus [returnStatus]{.underline}

2.  **Notes on the Behavior**

```{=html}
<!-- -->
```
a)  Consistent with unix file system.Recursive creation of directories
    is not supported.

b)  *SURL*may specify a new directory, as long as all parent directory
    hierarchy exists.

1.  **Return Status Code**

> **SRM\_SUCCESS**

-   **All requests are successfully completed.** *SURL***is created.**

> **SRM\_AUTHENTICATION\_FAILURE**

-   **SRM fails 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**

    1.  []{#_Toc199734382 .anchor}**srmRmdir**

srmRmdir removes an empty directory in a local SRM**.**

1.  **Parameters**

In: string authorizationID,

> anyURI [SURL]{.underline},

TExtraInfo\[\] storageSystemInfo,

boolean recursive

> Out: TReturnStatus [returnStatus]{.underline}

2.  **Notes on the Behavior**

```{=html}
<!-- -->
```
a)  **It applies to directories only**.To distinguish from *srmRm*(),
    this function is for directories only.

b)  *Input parameterrecursive*must be false by default.

c)  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 SRM, and may or may not be removed
    right away physically depending on the internal policy.

    1.  **Return Status Code**

> **SRM\_SUCCESS**

-   **All requests are successfully completed.** *SURL***is removed.**

> **SRM\_AUTHENTICATION\_FAILURE**

-   **SRM fails 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**

-   **input parameter *recursive* is not supported in the SRM**

    1.  []{#_Toc199734383 .anchor}**srmRm**

This function removes 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*must not remove SURLs or the
name space entries.

1.  **Parameters**

In: string authorizationID,

> anyURI\[\] [arrayOfSURLs]{.underline},

TExtraInfo\[\] storageSystemInfo

Out: TReturnStatus [returnStatus]{.underline},

> **TSURLReturnStatus**\[\] arrayOfFileStatuses

2.  **Notes on the Behavior**

```{=html}
<!-- -->
```
a)  To distinguish from *srmRmdir*(), this function applies to files
    only.

b)  *srmRm* removes all copies or states of SURLs in the storage, and
    removes the entry from the name space.

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

d)  *srmLs,srmPrepareToGet* or *srmBringOnline*must 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 must 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.*

    1.  **Return Status Code**

[]{#srmLs .anchor}**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 fails 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.**

    1.  []{#_Toc199734384 .anchor}**srmLs**

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

1.  **Parameters**

In: string authorizationID,

> anyURI \[\] [arrayOfSURLs]{.underline},
>
> TExtraInfo\[\] storageSystemInfo,

TFileStorageType fileStorageType,

boolean fullDetailedList,

> boolean allLevelRecursive,
>
> int numOfLevels,
>
> int offset,
>
> int count

Out: TReturnStatus [returnStatus]{.underline},

string requestToken,

> TMetaDataPathDetail\[\] details

2.  **Notes on the Behavior**

```{=html}
<!-- -->
```
a)  **Applies to both directories and files**

b)  *fullDetailedList*must be false by default**.**

    -   For directories, only path is required to be returned.

    -   For files, path and size are required to be returned.

```{=html}
<!-- -->
```
c)  If *fullDetailedList* is true, the full details must be 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, andtype*are required to be returned.

d)  If *allLevelRecursive* is true, then file lists of all level below
    current must be provided.

e)  If *allLevelRecursive* is \"true\", it dominates, i.e. SRM
    ignores*numOfLevels*. If *allLevelRecursive* is \"false\" or
    missing, then SRM uses*numOfLevels*. If *numOfLevels* is \"0\"
    (zero) or missing, SRM assumes a single level. If both
    *allLevelRecursive* and *numOfLevels* are missing, SRM assumes a
    single level.

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

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

h)  If *numOfLevels* is 1, then information about files in the directory
    must be returned. Negative value must be 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*",
    if supported, only the files with that type must be returned.

k)  Empty directories must 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.**

    1.  **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 fails 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 value for *numOfLevels*, *offset*or*count*is provided.**

-   **Operation on the path such as non-existing or system-prohibited
    file or directory may be prohibited.**

> **SRM\_NOT\_SUPPORTED**

-   **Requested *fileStorageType* is notsupported in SRM**

-   **Filtering *fileStorageType* is notsupported in SRM**

-   **Operation on the path such as browsing the top directory is not
    supported.*Explanation* needs to be filled for details.**

-   **Directory operation (directory SURL,** allLevelRecursive**or
    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 a file which there is an active srmPrepareToPut
    (no srmPutDone is yet called) request for**.**

> **SRM\_FILE\_LIFETIME\_EXPIRED**

-   **lifetime on *SURL* has 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 is not
    supported. *Explanation* needs to be filled for details.**

> **SRM\_FAILURE**

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

    1.  []{#_Toc199734385 .anchor}**srmStatusOfLsRequest**

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

1.  **Parameters**

In: string authorizationID,

> string [requestToken]{.underline},
>
> int offset,
>
> int count

Out: TReturnStatus [returnStatus]{.underline},

> TMetaDataPathDetail\[\] details

2.  **Notes on the Behavior**

```{=html}
<!-- -->
```
a)  Empty directories must be returned.

b)  **For non-existing files or directories in the client request,
    SRM\_INVALID\_PATH must be returned.**

    1.  **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 fails 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 value for *offset*or*count*is provided.**

> **SRM\_**INTERNAL\_ERROR

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

> **SRM\_NOT\_SUPPORTED**

-   **Requested *fileStorageType* is notsupported in SRM**

-   **Filtering *fileStorageType* is notsupported in SRM**

-   **Directory operation (directory SURL, browsing top directory,**
    allLevelRecursive**or 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 a file which there is an active srmPrepareToPut
    (no srmPutDone is yet called) request for**.**

> **SRM\_FILE\_LIFETIME\_EXPIRED**

-   **lifetime on *SURL* has 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 is not
    supported. *Explanation* needs to be filled for details.**

> **SRM\_FAILURE**

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

    1.  []{#_Toc136425010 .anchor}**srmMv**

srmMv moves a file or a directory to destination.

1.  **Parameters**

In: string authorizationID,

> anyURI [fromSURL]{.underline},

anyURI [toSURL]{.underline},

TExtraInfo\[\] storageSystemInfo

Out: TReturnStatus [returnStatus]{.underline}

2.  **Notes on the Behavior**

```{=html}
<!-- -->
```
a)  **Applies to both directories and files, and it 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\_FILE\_BUSY must be returned.

d)  Moving an SURL to itself results in no operation and SRM\_SUCCESS
    must be returned for no operation.

e)  When moving an SURL to already existing SURL,
    SRM\_DUPLICATION\_ERROR must be returned.

    1.  **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 fails 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 a file which there is an active srmPrepareToPut
    (no srmPutDone is yet called) request 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**

5.  **\
    **[]{#_Toc199734387 .anchor}**Data Transfer *Functions***

**summary:**

> [**srmPrepareToGet**](#_Toc199734388)
>
> **[srmStatusOfGetRequest](\l)[srmPrepareToPut](#_Toc199734392)**
>
> **[srmStatusOfPutRequest](\l)[srmCopy](#_Toc199734394)**
>
> [**srmStatusOfCopyRequest**](\l)
>
> [**srmBringOnline**](\l)
>
> [**srmStatusOfBringOnlineRequest**](\l)
>
> [**srmReleaseFiles**](#_Toc199734396)
>
> [**srmPutDone**](#_Toc199734397)
>
> [**srmAbortRequest**](#_Toc199734398)
>
> [**srmAbortFiles**](#_Toc199734399)
>
> [**srmSuspendRequest**](#_Toc199734400)
>
> [**srmResumeRequest**](#_Toc199734401)
>
> [**srmGetRequestSummary**](#_Toc199734402)

[**srmExtendFileLifeTime**](#srmExtendFileLifeTime)

> [**srmGetRequestTokens**](#_Toc199734404)

1.  []{#_Toc199734388 .anchor}**srmPrepareToGet**

This function is used to bring files online upon the client's request
and assign TURLs so that client can access the files. Lifetime (pinning
expiration time) is assigned on the TURL. When target space token is
specified,it must be refer to an online space, and the files must be
prepared using the space associated with the space token. It may be an
asynchronous operation, and request token must be returned in such case
if the client request is valid and accepted. The status may only be
checked through srmStatusOfGetRequest with the returned request token.

1.  **Parameters**

In: string authorizationID,

> TGetFileRequest\[\] [arrayOfFileRequests]{.underline},

string userRequestDescription,

> TExtraInfo\[\] storageSystemInfo,

TFileStorageType desiredFileStorageType,

int desiredTotalRequestTime,

int desiredPinLifetime,

> string targetSpaceToken,
>
> TRetentionPolicyInfo targetFileRetentionPolicyInfo,
>
> TTransferParameters transferParameters

Out: TReturnStatus [returnStatus]{.underline},

> string requestToken,
>
> TGetRequestFileStatus\[\] arrayOfFileStatuses,

int remainingTotalRequestTime

2.  **Notes on the Behavior**

```{=html}
<!-- -->
```
a)  The default value of "lifetime" for Volatile or Durable files may be
    the lifetime left in the space of the corresponding file type. The
    default value of "fileStorageType" is Volatile.

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

c)  Input parameter *targetFileRetentionPolicyInfo* of
    *TRetentionPolicyInfo* specifies 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 must be failed with
    SRM\_INVALID\_REQUEST.

e)  Access latency must be ONLINE always.

f)  If input parameter *TAccessPattern* is provided at the
    request-level, then all files must 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.

```{=html}
<!-- -->
```
o)  The *userRequestDescription* is a user designated name for the
    request. *It* is case-sensitive. SRM is expected to keep it as
    client provides. It may be reused by the client. It may be used in
    the *srmGetRequestTokens* function to get back the system assigned
    request tokens. *srmGetRequestTokens*must return all the request
    tokens that have the *userRequestDescription.*

```{=html}
<!-- -->
```
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*specifies a client-preferred
    lifetime (expiration time) on the prepared TURL.

j)  If the request is accepted and queued, SRM assigns the
    *requestToken* for asynchronous status checking. In such case, the
    returned status code must be SRM\_REQUEST\_QUEUED.

k)  *totalRequestTime* means: All the file transfer for this request
    must be completed 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, the request may be
    retried for a duration, which is dependent on the SRM, in case
    transient error occurs.

m)  If input parameter *desiredTotalRequestTime* is 0 (zero), each file
    request must be tried at least once. Negative value must be 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 must 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 must 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 must return SRM\_REQUEST\_QUEUED and keep trying
    the request for the duration of *desiredTotalRequestTime*. In the
    output parameter of explanation in *returnStatus*, the SRM may make
    explicit that the retry is being done. If streaming mode is not
    supported, the SRMmust return SRM\_NO\_USER\_SPACE or
    SRM\_NO\_FREE\_SPACE at the file level and SRM\_PARTIAL\_SUCCESS (if
    some file requests are successful) or SRM\_FAILURE at the request
    level.

r)  Zero length files must not fail on srmPrepareToGet.

    1.  **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 fails to authenticate the client**

> **SRM\_AUTHORIZATION\_FAILURE**

-   **client is not authorized to submit the request**

> **SRM\_INVALID\_REQUEST**

-   *arrayOfFileRequest* **is empty**

-   Input parameters *targetSpaceToken* and *TRetentionPolicyInfo*do not
    > match.

-   Access latency is something other than ONLINE.

```{=html}
<!-- -->
```
-   ***targetSpaceToken* does not refer to an existing known space in
    the SRM.**

> **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* files.**

> **SRM\_NO\_FREE\_SPACE**

-   **SRM space *is not enough to hold all requested* files *for
    free*.**

> **SRM\_NOT\_SUPPORTED**

-   **SRM does not support the given input parameters. For example,
    > client requests bbftp for the only transfer protocol, but SRM does
    > not support that. Client requests*desiredFileStorageType* that is
    > not supported by the SRM.**

-   *targetFileRetentionPolicyInfo* does not refer to a supported
    > retention policy in the SRM.

-   Directory operation is not supported in the SRM.

-   Recursive directory operation is not supported in the SRM.

-   None of the file transfer protocols are supported in the SRM.

> **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 a file which there is an active
    *srmPrepareToPut* (no *srmPutDone* is yet called) request for**.**

> SRM\_FILE\_UNAVAILABLE

-   the requested file is temporarily unavailable**.**

> **SRM\_INVALID\_PATH**

-   ***SURL* does not refer to an existing known file in SRM**

> **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* file.**

> **SRM\_NO\_FREE\_SPACE**

-   **SRM space *is not enough to hold requested* file *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.**

    1.  []{#_Toc199734389 .anchor}**srmStatusOfGetRequest**

This function checks the status of the previously requested
srmPrepareToGet. Request token from srmPrepareToGet must be provided.

1.  **Parameters**

In: string [requestToken]{.underline},

string authorizationID,

anyURI\[\] arrayOfSourceSURLs

Out: TReturnStatus [returnStatus]{.underline},

> TGetRequestFileStatus\[\] arrayOfFileStatuses,

int remainingTotalRequestTime

2.  **Notes on the Behavior**

```{=html}
<!-- -->
```
a)  The default value of "lifetime" for Volatile or Durable files may 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
    must be SRM\_FILE\_PINNED.

d)  When the file is ready for the client, the file is implicitly pinned
    in the cache and lifetime must 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 yet called) request 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 completed 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 must 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 must return SRM\_REQUEST\_QUEUED and keep trying
    the request for the duration of *desiredTotalRequestTime* from the
    request. *remainingTotalRequestTime*may be returned. In the output
    parameter of explanation in *returnStatus*, the SRM may make
    explicit that the retry is being done. If streaming mode is not
    supported, the SRM must return SRM\_NO\_USER\_SPACE or
    SRM\_NO\_FREE\_SPACE at the file level and SRM\_PARTIAL\_SUCCESS (if
    some file requests are successful) or SRM\_FAILURE at the request
    level. Clients may need to release files or clean up the target
    space when target space token is provided in the request.

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.

    1.  **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 fails 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.**

> **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 files*.**

> **SRM\_NO\_USER\_SPACE**

-   **user space *is not enough to hold all requested* files.**

> **SRM\_NO\_FREE\_SPACE**

-   **SRM space *is not enough to hold all requested* files *for
    free*.**

> **SRM\_NOT\_SUPPORTED**

-   **SRM does not support the given input parameters. For example,
    > client requests bbftp for the only transfer protocol, but SRM does
    > not support that. Client requests*desiredFileStorageType* that is
    > not supported by the SRM.**

-   *targetFileRetentionPolicyInfo* does not refer to a supported
    > retention policy in the SRM.

-   Directory operation is not supported in the SRM.

-   Recursive directory operation is not supported in the SRM.

-   None of the file transfer protocols are supported in the SRM.

> **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 a file which there is an active
    *srmPrepareToPut* (no *srmPutDone* is yet called) request 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**

-   ***SURL* does not refer to an existing file in SRM**

> **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* file.**

> **SRM\_NO\_FREE\_SPACE**

-   **SRM space *is not enough to hold requested* file *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.**

    1.  []{#_Toc199734390 .anchor}**srmBringOnline**

This function brings files online upon the client 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 refer to an
online space, the files must be brought online using the space
associated with the space token. It may be an asynchronous operation,
and request token must be returned if asynchronous operation is
necessary in SRM. The status may only be checked through
*srmStatusOfBringOnlineRequest* with the returned request token.

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

1.  **Parameters**

In: string authorizationID,

> TGetFileRequest\[\] [arrayOfFileRequests]{.underline},

string userRequestDescription,

> TExtraInfo\[\] storageSystemInfo,

TFileStorageType desiredFileStorageType,

int desiredTotalRequestTime,

int desiredLifetime, // lifetime on online

> string targetSpaceToken,
>
> TRetentionPolicyInfo targetFileRetentionPolicyInfo,
>
> TTransferParameters transferParameters,

int deferredStartTime

Out: TReturnStatus [returnStatus]{.underline},

> string requestToken,
>
> TBringOnlineRequestFileStatus\[\] arrayOfFileStatuses,

int remainingTotalRequestTime,

int remainingDeferredStartTime

2.  **Notes on the Behavior**

```{=html}
<!-- -->
```
a)  Optional 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 must be invalid.

b)  Output parameter *remainingDeferredStartTime* indicates how long the
    deferredStartTime is left, if supported. Negative value mustbe
    invalid.

c)  Input parameter *targetFileRetentionPolicyInfo* of
    *TRetentionPolicyInfo* specifies 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 must be failed, and
    SRM\_INVALID\_REQUEST must 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, when supported.

g)  Access latency after the operation is successful must be ONLINE, and
    the file may also be on NEARLINE as well.

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

i)  The *userRequestDescription* is a user designated name for the
    request. *It* is case-sensitive. SRM must keep it as client
    provides. It may be reused by the client. It can be used in the
    *srmGetRequestTokens* function to get back the system assigned
    request tokens. *srmGetRequestTokens*must 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, accepted and
    queued. The returned status code must be SRM\_REQUEST\_QUEUED. To
    get subsequent status and results, separate calls must be made
    through srmStatusOfBringOnline.

l)  The returned request token must 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 completed 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, the
    request may be retried for a duration which is dependent on the SRM,
    in case transient error occurs.

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

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 must 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 must return SRM\_REQUEST\_QUEUED and keep trying
    the request for the duration of *desiredTotalRequestTime*. In the
    output parameter of explanation in *returnStatus*, the SRM may make
    explicit that the retry is being done. If streaming mode is not
    supported, the SRM must return SRM\_NO\_USER\_SPACE or
    SRM\_NO\_FREE\_SPACE at the file level and SRM\_PARTIAL\_SUCCESS (if
    some file requests are successful) or SRM\_FAILURE at the request
    level.

    1.  **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 fails 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.**

-   Input parameters *targetSpaceToken* and *TRetentionPolicyInfo*do not
    > match.

```{=html}
<!-- -->
```
-   ***targetSpaceToken* does not refer to an existing known space in
    the SRM.**

-   ***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 files*.**

> **SRM\_NO\_USER\_SPACE**

-   **user space *is not enough to hold all requested* files.**

> **SRM\_NO\_FREE\_SPACE**

-   **SRM space *is not enough to hold all requested* files *for
    free*.**

> **SRM\_**INTERNAL\_ERROR

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

> **SRM\_NOT\_SUPPORTED**

-   **SRM does not support the given input parameters. For example,
    > client requests bbftp for the only transfer protocol, but SRM
    > cannot support that. Client requests*desiredFileStorageType* that
    > is not supported by the SRM.**

-   *targetFileRetentionPolicyInfo* does not refer to a supported
    > retention policy in the SRM.

-   *GivendeferredStartTime* is not supported in the SRM.

-   Directory operation is not supported in the SRM.

-   Recursive directory operation is not supported in the SRM.

-   None of the given file transfer protocols are 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 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 a file which there is an active
    *srmPrepareToPut* (no *srmPutDone* is yet called) request for**.**

> SRM\_FILE\_UNAVAILABLE

-   the requested file is temporarily unavailable**.**

> **SRM\_INVALID\_PATH**

-   ***SURL* does not refer to an existing known file in SRM**

> **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* file.**

> **SRM\_NO\_FREE\_SPACE**

-   **SRM space *is not enough to hold requested* file *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.**

    1.  []{#_Toc199734391 .anchor}**srmStatusOfBringOnlineRequest**

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

1.  **Parameters**

In: string [requestToken]{.underline},

string authorizationID,

anyURI\[\] arrayOfSourceSURLs

Out: TReturnStatus [returnStatus]{.underline},

> TBringOnlineRequestFileStatus\[\] arrayOfFileStatuses,

int remainingTotalRequestTime,

int remainingDeferredStartTime

2.  **Notes on the Behavior**

```{=html}
<!-- -->
```
a)  If *arrayOfSourceSURLs* is not provided, all files in the request
    must be returned.

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 must
    beinvalid.

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 yet called) request 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 completed 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 must 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 must return SRM\_REQUEST\_QUEUED and keep trying
    the request for the duration of *desiredTotalRequestTime* from the
    request. *remainingTotalRequestTime*may be returned. In the output
    parameter of explanation in *returnStatus*, the SRM may make
    explicit that the retry is being done. If streaming mode is not
    supported, the SRM must return 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 is provided.

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

    1.  **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 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.**

> **SRM\_NOT\_SUPPORTED**

-   **SRM does not support the given input parameters. For example,
    > client requests bbftp for the only transfer protocol, but SRM
    > cannot support that. Client requests*desiredFileStorageType* that
    > is not supported by the SRM.**

-   *targetFileRetentionPolicyInfo* does not refer to a supported
    > retention policy in the SRM.

-   *deferredStartTime* is not supported in the SRM.

-   Directory operation is not supported in the SRM.

-   Recursive directory operation is not supported in the SRM.

-   None of the file transfer protocols are supported in the SRM.

> **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 files*.**

> **SRM\_NO\_USER\_SPACE**

-   **user space *is not enough to hold all requested files*.**

> **SRM\_NO\_FREE\_SPACE**

-   **SRM space *is not enough to hold all requested files 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 a file which there is an active
    *srmPrepareToPut* (no *srmPutDone* is yet called) request 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* file.**

> **SRM\_NO\_FREE\_SPACE**

-   **SRM space *is not enough to hold requested* file *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.**

    1.  []{#_Toc199734392 .anchor}**srmPrepareToPut**

This function is used to write files into the storage. Upon the client
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
may be an asynchronous operation, and request token must be returned if
the request is valid, accepted and queued to the SRM. The status may
only be checked through srmStatusOfPutRequest with the returned request
token.

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]{.underline},

> string requestToken,
>
> TPutRequestFileStatus\[\] arrayOfFileStatuses,

int remainingTotalRequestTime

2.  **Notes on the Behavior**

```{=html}
<!-- -->
```
a)  The default value of "lifetime" for Volatile or Durable files may 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 must keep it as client provides.
    It may be reused by the client. It can be used in the
    *srmGetRequestTokens* function to get back the system assigned
    request tokens. *srmGetRequestTokens*must return all the request
    tokens that have the *userRequestDescription.*

e)  When optional input parameter *targetSpaceToken* is provided at the
    request-level, 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)  Optional input parameter *targetFileRetentionPolicyInfo* of
    *TRetentionPolicyInfo* specifies 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 must be failed 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*must to be
    local to SRM. If *targetSURL* is not specified, SRM may generate a
    reference SURL for the file request automatically and put it in the
    specified user space if provided. Then, this reference SURL must 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)  Optional 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 must 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 SRM must return SRM\_FAILURE at the file level.*

l)  Optional 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 successful srmPutDone is executed.

m)  The lifetime of the SURL starts as soon as SRM receives the
    *srmPutDone*(). If *srmPutDone*() is not provided, then the file in
    that space is 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 and queued, SRM assigns the *requestToken*
    for asynchronous status checking. In such case, the returned status
    code must be SRM\_REQUEST\_QUEUED.

o)  *totalRequestTime* means: All the file transfer for the request must
    be completed within the*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 must be retried for a duration which is dependent on the
    SRM.

q)  If input parameter *desiredTotalRequestTime* is 0 (zero), each file
    request must be tried at least once. Negative value must be 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 must 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 must return SRM\_REQUEST\_QUEUED and keep trying
    the request for the duration of *desiredTotalRequestTime* from the
    request. In the output parameter of explanation in *returnStatus*,
    the SRM may make explicit that the retry is being done. If streaming
    mode is not supported, the SRMmust return SRM\_NO\_USER\_SPACE or
    SRM\_NO\_FREE\_SPACE at the file level and SRM\_PARTIAL\_SUCCESS (if
    some file requests are 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 is 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, otherwise the request must be
    processed.

w)  After TURL is returned, *srmMv* operation on the corresponding SURL
    may be requested. *srmPutDone* on the original SURL must be
    succesful, 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.

    1.  **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 failS 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.

```{=html}
<!-- -->
```
-   ***targetSpaceToken* does not refer to an existing known space in
    the SRM.**

> **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* files.**

> **SRM\_NO\_FREE\_SPACE**

-   **SRM space *is not enough to hold all requested* files *for
    free*.**

> **SRM\_**INTERNAL\_ERROR

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

> **SRM\_NOT\_SUPPORTED**

-   **SRM does not support the given input parameters. For example,
    > client requests bbftp for the only transfer protocol, but SRM
    > cannot support that. Client requests*desiredFileStorageType* that
    > is not supported by the SRM.**

-   *targetFileRetentionPolicyInfo* does not refer to a supported
    > retention policy in the SRM.

-   None of the file transfer protocols are 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\_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
    permitted.***

> SRM\_FILE\_BUSY

-   client requests for files which there is an active srmPrepareToPut
    (no srmPutDone is yet called) or srmCopy request for**.**

> **SRM\_AUTHORIZATION\_FAILURE**

-   **client is not authorized to write 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* file.**

> **SRM\_NO\_FREE\_SPACE**

-   **SRM space *is not enough to hold the requested* file *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.**

    1.  []{#_Toc199734393 .anchor}**srmStatusOfPutRequest**

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

1.  **Parameters**

In: string [requestToken]{.underline},

string authorizationID,

anyURI\[\] arrayOfTargetSURLs

Out: TReturnStatus [returnStatus]{.underline},

> TPutRequestFileStatus\[\] arrayOfFileStatuses,

int remainingTotalRequestTime

2.  **Notes on the Behavior**

```{=html}
<!-- -->
```
a)  The default value of "lifetime" for Volatile or Durable files may 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, all the file statuses in
    the request must be returned.

c)  When the space is ready for client to "put" data and TURL is
    prepared, the return status code must 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 must be enforced. TURLs
    must not be valid any more after the *pin lifetime is over if
    srmPutDone or srmAbortRequest is not submitted on the SURL before
    the expiration. In such case, the SRM must return SRM\_FAILURE at
    the file level.*

e)  If a *targetSURL* is provided with some directory structure, the
    directory structure must exist, and SRM must 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 by the client.

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 fail.

i)  *totalRequestTime* means: All the file transfer for this request
    must be completed within the*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 must 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 must return SRM\_REQUEST\_QUEUED and keep trying
    the request for the duration of *desiredTotalRequestTime* from the
    request. *remainingTotalRequestTime*may be returned. In the output
    parameter of explanation in *returnStatus*, the SRM may make
    explicit that the retry is being done. If streaming mode is not
    supported, the SRM must return SRM\_NO\_USER\_SPACE or
    SRM\_NO\_FREE\_SPACE at the file level and SRM\_PARTIAL\_SUCCESS (if
    some file requests are successful) or SRM\_FAILURE at the request
    level. Clients may need to clean up the target space when target
    space token is provided.

l)  Upon srmPrepareToPut, SURL entry is added 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 is 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 must 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 must be
    successful, 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
    is specified in the input for specific file statuses.

    1.  **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 fails 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.**

```{=html}
<!-- -->
```
-   ***targetSpaceToken* that client provided does not refer to an
    existing space in the SRM.**

> **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* files.**

> **SRM\_NO\_USER\_SPACE**

-   **user space *is not enough to hold all requested* files.**

> **SRM\_NO\_FREE\_SPACE**

-   **SRM space *is not enough to hold all requested* files *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 does not support the given input parameters. For example,
    > client requests bbftp for the only transfer protocol, but SRM
    > cannot support that. Client requests*desiredFileStorageType* that
    > is not supported by the SRM.**

-   *targetFileRetentionPolicyInfo* does not refer to a supported
    > retention policy in the SRM.

-   None of the file transfer protocols are 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\_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
    permitted.***

> SRM\_FILE\_BUSY

-   client requests for files which there is an active srmPrepareToPut
    (no srmPutDone is yet called) or srmCopy request for**.**

> **SRM\_AUTHORIZATION\_FAILURE**

-   **client is not authorized to write 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* file.**

> **SRM\_NO\_FREE\_SPACE**

-   **SRM space *is not enough to hold the requested* file *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.**

    1.  []{#_Toc199734394 .anchor}**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
to. 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) to, 2. Source SRM is where
client makes a srmCopy request (PUSH case) to.

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
    SRM 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 a specified target space token is provided, the files will be
located finally in the targeted space associated with the space token.
It may an asynchronous operation, and request token must be returned in
such case. The status may only be checked through srmStatusOfCopyRequest
with the returned request token.

1.  **Parameters**

In: string authorizationID,

> TCopyFileRequest\[\] [arrayOfFileRequests]{.underline},

string userRequestDescription,

TOverwriteMode overwriteOption,

int desiredTotalRequestTime,

int desiredTargetSURLLifeTime,

TFileStorageType targetFileStorageType,

> string targetSpaceToken,
>
> TRetentionPolicyInfo targetFileRetentionPolicyInfo,

TExtraInfo\[\] sourceStorageSystemInfo,

TExtraInfo\[\] targetStorageSystemInfo

Out: TReturnStatus [returnStatus]{.underline},

> string requestToken,
>
> TCopyRequestFileStatus\[\] arrayOfFileStatuses,

int remainingTotalRequestTime

2.  **Notes on the Behavior**

```{=html}
<!-- -->
```
a)  The default value of *desiredTargetSURLLifeTime* for Volatile or
    Durable files may be the lifetime left in the space of the
    corresponding file type. The default value of
    *targetFileStorageType* is Volatile.

b)  When aborted, target SURLs must be provided.

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

d)  If optional input parameter *targetSpaceToken* is provided at the
    request-level, then 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* specifies 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 must be failed, and
    SRM\_INVALID\_REQUEST must be returned.

g)  If request is accepted and queued, SRM must assign the
    *requestToken* for asynchronous status checking. In such case, the
    returned status code must be SRM\_REQUEST\_QUEUED.

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

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

j)  SRM must always release files through *srmReleaseFiles* from the
    source after copy is completed, if source is an SRM and PULL mode is
    performed.

k)  SRM must always issue *srmPutDone* to the target after copy is
    completed, if target is an SRM and PUSH mode is performed.

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

m)  *totalRequestTime* means: All the file transfer for the request must
    be completed in this *totalRequestTime*. Otherwise, the request must
    be 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 must be retried for a duration which is dependent on the
    SRM.

o)  If input parameter *desiredTotalRequestTime* is 0 (zero), each file
    request must be tried at least once. Negative value must be 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 must 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 must 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 supports, then all sub directories
    must be copied over from the source to the target, and complete
    sub-directory structure must 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 must return SRM\_REQUEST\_QUEUED and keep trying
    the request for the duration of *desiredTotalRequestTime* from the
    request. In the output parameter of explanation in *returnStatus*,
    the SRM may make explicit that the retry is being done. If streaming
    mode is not supported, the SRM must return SRM\_NO\_USER\_SPACE or
    SRM\_NO\_FREE\_SPACE at the file level and SRM\_PARTIAL\_SUCCESS (if
    some file requests are successful) or SRM\_FAILURE at the request
    level. Clients may need to clean up the target space when target
    space token is provided.

v)  Upon srmCopy request, 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 are 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.

    1.  **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 fails 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.

```{=html}
<!-- -->
```
-   ***targetSpaceToken* does not refer to an existing known space in
    the SRM.**

> **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 does not support the given input parameters. For example,
    > client requests*desiredFileStorageType* that is not supported by
    > the SRM.**

-   *targetFileRetentionPolicyInfo* does not refer to a supported
    > retention policy in the SRM.

-   Directory operation is not supported in the SRM.

-   Recursive directory operation is not supported in the SRM.

-   **A specified input parameter is not supported in the SRM.**

-   ***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 file. The *sourceSURL* 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 yet called) request
    for**.**

-   client requests for files at the target (*targetSURL*) which there
    is an active srmPrepareToPut (no srmPutDone is yet called) or
    srmCopy request 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
    permitted.***

> **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
    provides 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.**

    1.  []{#_Toc199734395 .anchor}**srmStatusOfCopyRequest**

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

1.  **Parameters**

In: string [requestToken]{.underline},

string authorizationID,

anyURI\[\] arrayOfSourceSURLs,

anyURI\[\] arrayOfTargetSURLs

Out: TReturnStatus [returnStatus]{.underline},

> TCopyRequestFileStatus\[\] arrayOfFileStatuses,

int remainingTotalRequestTime

2.  **Notes on the Behavior**

```{=html}
<!-- -->
```
a)  If *arrayOfSourceSURLs* and/or *arrayOfTargetSURLs* are not
    provided, all file statuses in the request must be returned.

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 the request must
    be completed 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)  Optional 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 must
    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 must return SRM\_REQUEST\_QUEUED and keep trying
    the request for the duration of *desiredTotalRequestTime* from the
    request. *remainingTotalRequestTime* is being returned. In the
    output parameter of explanation in *returnStatus*, the SRM may make
    explicit that the retry is being done. If streaming mode is not
    supported, the SRM must return SRM\_NO\_USER\_SPACE or
    SRM\_NO\_FREE\_SPACE at the file level and SRM\_PARTIAL\_SUCCESS (if
    some file requests arere 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 request, 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 are 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 must 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.

    1.  **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 fails 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.**

```{=html}
<!-- -->
```
-   ***targetSpaceToken* does not refer to an existing known space in
    the SRM.**

> **SRM\_TOO\_MANY\_RESULTS**

-   **Request produced too many results that SRM 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 user space.**

> **SRM\_NO\_FREE\_SPACE**

-   **SRM space *is not enough to hold requested* file *for free*.**

> **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 does not support the given input parameters. For example,
    > client requests bbftp for the only transfer protocol, but SRM
    > cannot support that. Client requests*desiredFileStorageType* that
    > is not supported by the SRM.**

-   *targetFileRetentionPolicyInfo* does not refer to a supported
    > retention policy in the SRM.

-   Overwrite option is not supported in the SRM.

-   Directory operation is not supported in the SRM.

-   Recursive directory operation is not supported in the SRM.

-   **a specified input parameter is not supported in the SRM.**

-   ***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 file. The *sourceSURL* is
    successfully copied into the target destination *targetSURL*, 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 yet called) request
    for**.**

-   client requests for files at the target (*targetSURL*) which there
    is an active srmPrepareToPut (no srmPutDone is yet called) or
    srmCopy request 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**

-   *sourceSURL* 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
    provides 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.**

    1.  []{#_Toc199734396 .anchor}**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 function.

1.  **Parameters**

In: string requestToken,

string authorizationID,

anyURI\[\] arrayOfSURLs,

Boolean doRemove

Out: TReturnStatus [returnStatus]{.underline},

> TSURLReturnStatus\[\] arrayOfFileStatuses

2.  **Notes on the Behavior**

```{=html}
<!-- -->
```
a)  *doRemove* by default is false. If *doRemove* is true, the pin on
    the file must be released, the "copy" or "state" must be removed. It
    must not remove SURLs, and srmRm must be used to remove SURLs.

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

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

d)  *If requestToken is provided and SURLs are not provided, then the
    SRM must 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 request.*

g)  *srmReleaseFiles is only valid after successful srmPrepareToGet or
    srmBringOnlinerequest. To release TURLs after a srmPrepareToPut,
    srmAbortRequest or srmAbortFiles must be used. If a client submits
    srmReleaseFiles after srmPrepareToPut or srmPutDone, then the SRM
    must return SRM\_INVALID\_REQUEST.*

    1.  **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 fails to authenticate the client**

> **SRM\_AUTHORIZATION\_FAILURE**

-   **client is not authorized to release files**

> **SRM\_INVALID\_REQUEST**

-   ***arrayOfSURLs* is empty.**

```{=html}
<!-- -->
```
-   ***requestToken* does not refer to an existing known request of
    > *srmPrepareToGet* or *srmBringOnline* in the SRM.**

> **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.***

**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 *doRemove* flag is on**

> **SRM\_FILE\_LIFETIME\_EXPIRED**

-   ***SURLis expired already*.**

> **SRM\_ABORTED**

-   **The requested file has been aborted.**

> **SRM\_FAILURE**

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

    1.  []{#_Toc199734397 .anchor}**srmPutDone**

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

1.  **Parameters**

In: string [requestToken]{.underline},

string authorizationID,

anyURI\[\] [arrayOfSURLs]{.underline}

Out: TReturnStatus [returnStatus]{.underline},

> TSURLReturnStatus\[\] arrayOfFileStatuses

2.  **Notes on the Behavior**

```{=html}
<!-- -->
```
a)  Client calls srmPutDone after srmPrepareToPut() prepares the TURL
    and the client completes the file transfer into the prepared TURL.

b)  *srmRm must 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 is 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.

    1.  **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 fails 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.**

> 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 is performed on the *targetSURL***

> **SRM\_AUTHORIZATION\_FAILURE**

-   **client is not authorized to call the request *srmPutDone*() on the
    *targetSURL***

> **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 has been aborted.**

> **SRM\_FAILURE**

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

    1.  []{#_Toc199734398 .anchor}**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 must
attempt a complete cleanup of running transfers and files in
intermediate state.**

1.  **Parameters**

In: string [requestToken]{.underline},

string authorizationID

Out: TReturnStatus [returnStatus]{.underline}

2.  **Notes on the Behavior**

```{=html}
<!-- -->
```
a)  *srmAbortRequest terminates 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 must
    remain in the space where they are brought in and must not be
    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 srmPrepareToPut request 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.

    1.  **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
    are successfully completed already.**

> **SRM\_AUTHENTICATION\_FAILURE**

-   **SRM fails 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.**

> **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**

    1.  []{#_Toc199734399 .anchor}**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.**

1.  **Parameters**

In: string [requestToken]{.underline},

anyURI\[\] [arrayOfSURLs]{.underline},

string authorizationID

Out: TReturnStatus [returnStatus]{.underline},

> TSURLReturnStatus\[\] arrayOfFileStatuses

2.  **Notes on the Behavior**

```{=html}
<!-- -->
```
a)  srmAbortFiles aborts all files in the request regardless of the
    state.

b)  When aborting srmCopy request, the srmCopy 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 request, all uncompleted files must be
    aborted, and all successfully completed files must be released.

d)  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.*

e)  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.

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

g)  srmAbortFiles 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 must be returned to all duplicate abort file requests
    and no operations on duplicate abort file requests must performed.

    1.  **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 faild 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.**

> **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.**

    1.  []{#_Toc199734400 .anchor}**srmSuspendRequest**

srmSuspendedRequest is used to suspend a previously submitted active
request**.**

1.  **Parameters**

In: string [requestToken]{.underline},

string authorizationID

Out: TReturnStatus [returnStatus]{.underline}

2.  **Notes on the Behavior**

```{=html}
<!-- -->
```
a)  Suspend all files in the request until srmResumeRequest or
    srmAbortRequest is requested.

    1.  **Return Status Code**

> **SRM\_SUCCESS**

-   **successful request completion. Request is suspended
    successfully.**

> **SRM\_AUTHENTICATION\_FAILURE**

-   **SRM fails 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.**

```{=html}
<!-- -->
```
-   ***requestToken* does not refer to an existing known request in the
    > SRM.**

> **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**

    1.  []{#_Toc199734401 .anchor}**srmResumeRequest**

srmResumeRequest is used to resume previously suspended request**.**

1.  **Parameters**

In: string [requestToken]{.underline},

string authorizationID

> Out: TReturnStatus [returnStatus]{.underline}

2.  **Notes on the Behavior**

```{=html}
<!-- -->
```
a)  Resume the previously suspended request.

    1.  **Return Status Code**

> **SRM\_SUCCESS**

-   **successful request completion. Request is resumed successfully.**

> **SRM\_AUTHENTICATION\_FAILURE**

-   **SRM fails 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.**

```{=html}
<!-- -->
```
-   ***requestToken* does not refer to an existing known request in the
    > SRM.**

> **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**

    1.  []{#_Toc199734402 .anchor}**srmGetRequestSummary**

srmGetRequestSummaryis used to retrieve a summary of the previously
submitted request**.**

1.  **Parameters**

In: string \[\] [arrayOfRequestTokens]{.underline},

string authorizationID

Out: TReturnStatus [returnStatus]{.underline},

> TRequestSummary\[\] arrayOfRequestSummaries

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 fails 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 fails to get summaries of all requests that are associated
    with request tokens.**

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

**For each request level return status,**

**SRM\_INVALID\_REQUEST**

-   ***requestToken* does not refer to an existing known request in the
    > SRM.**

> **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.**

    1.  []{#_Toc199734403 .anchor}**srmExtendFileLifeTime**

**srmExtendFileLifeTime() allows clients to extend lifetime of existing
*SURL*s of volatile and durable file storage types or lifetime of
*pinned files (TURLs* of the results of *srmPrepareToGet,srmPrepareToPut
or srmBringOnline*).**

1.  **Parameters**

In: string authorizationID,

> string requestToken,

anyURI\[\] [arrayOfSURLs]{.underline},

int newFileLifetime,

int newPinLifetime

Out: TReturnStatus [returnStatus]{.underline},

TSURLLifetimeReturnStatus \[\] arrayOfFileStatuses

2.  **Notes on the Behavior**

```{=html}
<!-- -->
```
a)  srmExtendFileLifeTime allows to change only one type of 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.
    Either*newFileLifetime*or*newPinLifetime*must be provided. When both
    *newFileLifetime* and *newPinLifetime* are provided in the same
    request, the request must be invalid, and SRM\_INVALID\_REQUEST 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 must be assigned.

g)  When none of lifetime input parameters
    (*newPinLifetime*and*newFileLifetime*) is specified, the SRM must
    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 for
    srmPrepareToPut request. 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)  srmExtendFileLifeTimeintends to negotiate a request of extension of
    file or pin lifetime. If input parameter *newFileLifetime* or
    *newPinLifetime* exceeds the remaining lifetime of the space where
    SURLs are, then SRM\_SUCCESS is returned at the request and at the
    file level, and *TSURLLifetimeReturnStatus*must contain the
    remaining lifetime of the space.

k)  Lifetime extension must fail on SURLs when their status is
    SRM\_FILE\_BUSY.

    1.  **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 fails 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.**

-   ***requestToken is not provided, and extending pinning lifetime of
    TURLs associated with SURLs requiresrequestToken.***

> **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 *SURLis 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.**

    1.  []{#_Toc199734404 .anchor}**srmGetRequestTokens**

srmGetRequestTokens retrieves request tokens for the client, using
specified request description. This is to accommodate lost request
tokens. This can also be used for getting all request tokens back that
belong to the client.

1.  **Parameters**

In: string userRequestDescription,

string authorizationID

> Out: TReturnStatus [returnStatus]{.underline},
>
> TRequestTokenReturn\[\] arrayOfRequestTokens

2.  **Notes on the Behavior**

```{=html}
<!-- -->
```
a)  If *userRequestDescription* is null, srmGetRequestTokens must return
    all request tokens that belong to the client.

b)  If the client assigns the same description to multiple requests, the
    client may get back multiple request tokens each with the time the
    request is created.

    1.  **Return Status Code**

> **SRM\_SUCCESS**

-   **successful request completion. Request tokens are returned
    successfully.**

> **SRM\_AUTHENTICATION\_FAILURE**

-   **SRM fails 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.  []{#_Toc199734405 .anchor}**Discovery *Functions***

***summary:***

> [**srmGetTransferProtocols**](\l)

[**srmPing**](\l)

1.  []{#_Toc199734406 .anchor}**srmGetTransferProtocols**

srmGetTransferProtocols is used to discover what transfer protocols are
supported by the SRM.

1.  **Parameters**

In: string authorizationID

Out: TReturnStatus [returnStatus]{.underline},

TSupportedTransferProtocol\[\] protocolInfo

2.  **Notes on the Behavior**

```{=html}
<!-- -->
```
a)  *srmGetTransferProtocols***()** returns the supported file transfer
    protocols in the SRM with any additional information about the
    transfer protocol**.**

    1.  **Return Status Code**

> **SRM\_SUCCESS**

-   **successful request completion. List of supported transfer
    protocols are returned successfully.**

> **SRM\_AUTHENTICATION\_FAILURE**

-   **SRM fails to authenticate the client**

> **SRM\_AUTHORIZATION\_FAILURE**

-   **client is not authorized to request transfer protocol
    > 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.**

    1.  []{#_Toc188720194 .anchor}**srmPing**

srmPing is used to check the state of the SRM. It works as an "are you
alive" type of call.

1.  **Parameters**

In: string authorizationID

Out: string [versionInfo]{.underline},

TExtraInfo\[\] otherInfo

2.  **Notes on the Behavior**

```{=html}
<!-- -->
```
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*.

```{=html}
<!-- -->
```
7.  []{#_Toc199734408 .anchor}**Storage Resource Managers Concepts**

    1.  []{#_Toc199734409 .anchor}**Summary**

Storage management is one of the most important enabling technologies
for large-scale scientific investigations. Having to deal with multiple
heterogeneous storage and file systems is one of the major bottlenecks
in managing, replicating, and accessing files in distributed
environments. Storage Resource Managers (SRMs), named after their web
services protocol, provide the technology needed to manage the rapidly
growing distributed data volumes, as a result of faster and larger
computational facilities. SRMs are Grid storage services providing
interfaces to storage resources, as well as advanced functionality such
as dynamic space allocation and file management on shared storage
systems. They call on transport services to bring files into their space
transparently and provide effective sharing of files. SRMs are based on
a common specification that emerged over time and evolved as an
international collaboration. This approach of an open specification that
can be used by various institutions to adapt to their own storage
systems has proven to be a remarkable success -- the challenge has been
to provide a consistent homogeneous interface to the Grid, while
allowing sites to have diverse infrastructures. In particular, one of
the main goals to the SRM web service is to support optional features
while preserving interoperability. The specification of the version
described in this document, SRM v2.2, was also influenced by needs of a
large international High Energy Physics collaboration, called WLCG,
which adapted the SRM standard in order to handle the large volume of
data expected when the Large Hadron Collider (LHC) goes online at CERN.
This intense collaboration led to refinements and additional
functionality in the SRM specification, and the development of multiple
interoperating implementations of SRM for various complex
multi-component storage systems.

2.  []{#_Toc199734410 .anchor}**Overview**

**Increases in computational power have created the opportunity for new,
more precise and complex scientific simulations leading to new
scientific insights. Similarly, large experiments generate ever
increasing volumes of data. At the data generation phase, large volumes
of storage have to be allocated for data collection and archiving. At
the data analysis phase, storage needs to be allocated to bring a subset
of the data for exploration, and to store the subsequently generated
data products. Furthermore, storage systems shared by a community of
scientists need a common data access mechanism which allocates storage
space dynamically, manages stored content, and automatically removes
unused data to avoid clogging data stores.**

**When dealing with storage, the main problems facing users today are
the need to interact with a variety of storage systems and to
pre-allocate storage to ensure that data generation and analysis tasks
can take place successfully. Typically, each storage system provides
different interfaces and security mechanisms. There is an urgent need to
standardize and streamline the access interface, the dynamic storage
allocation and the management of the content of these systems. The goal
is to present to the users the same interface regardless of the type of
system being used. Ideally, the management of storage allocation should
become transparent.**

**To accommodate this need, the concept of Storage Resource Managers
(SRMs) was devised \[SSG02, SSG03\] in the context of a project that
involved High Energy Physics (HEP) and Nuclear Physics (NP). SRM is a
specific set of web services protocols used to control storage systems
from the Grid, and should not be confused with the more general concept
of Storage Resource Management as used in industry, where Storage
Resource Management refers to the process of optimizing the efficiency
and speed of storage devices (primary and secondary) and the efficient
backup and recovery of data. By extension, a Grid component providing an
SRM interface is usually called "an SRM."**

**After recognizing the value of this concept as a way to interact with
multiple storage systems in a uniform way, several U.S. Department of
Energy Laboratories (LBNL, FNAL, and TJNAF), as well as CERN and RAL in
Europe, joined forces and formed a collaboration that evolved into a
stable version, called SRM v1.1, that they all adopted. This led to the
development of SRMs for several disk-based systems and mass storage
systems, including HPSS \[hpss\] (at LBNL), CASTOR \[castor\] (at CERN),
Enstore \[enstore\] (at FNAL), and JasMINE \[jasmine\] (at TJNAF). The
interoperation of these implementations was demonstrated and proved to
be an attractive concept. However, the functionality of SRM v1.1 was
limited, since space was allocated by default policies, and there was no
support for directory structures.**

**Subsequent collaboration efforts led to advanced features such as
explicit space reservations, directory management, and support for
Access Control Lists (ACL) to be supported by the SRM protocol, referred
to as version 2.1. As with many advanced features, it was optional for
the implementations to support them in order to be inclusive of
implementations choosing not to support specific features.**

**Later, when a large international HEP collaboration, WLCG (the
World-wide LHC Computing Grid) \[wlcg-collab\] decided to adopt the SRM
standard, it became clear that many concepts needed clarification, and
new functionality was added, resulting in SRM v2.2. While the WLCG
contribution has been substantial, SRMsare also used by other Grids,
such as the EGEE gLite software \[glite\], or the Earth System Grid
\[esg\]. There are many such Grids, often collaborations between the EU
and developing countries. Having open source and license-free
implementations based on the same standard is the best way to share this
middleware technology.**

**The collaboration is open to any institution willing and able to
contribute. For example, when INFN, the Italian institute for nuclear
physics, started working on their own SRM implementation they joined the
collaboration. The collaboration also has an official standards body,
the Open Grid Forum, OGF, where it is registered as GSM-WG (GSM is Grid
Storage Management; the acronym SRM was already taken for a different
purpose in OGF).**

3.  []{#_Toc199734411 .anchor}**The Basic Concepts**

**The ideal vision of a distributed Grid-based system is to have
middleware facilities that give clients the illusion that all the
compute and storage resources needed for their jobs are running on their
local system. This implies that a client only logs in and gets
authenticated once, and that some middleware software figures out where
are the most efficient locations to move data to, to run the job, and to
store the results in. The middleware software plans the execution,
reserves compute and storage resources, executes the request, and
monitors the progress. The traditional emphasis is on sharing large
compute resource facilities, sending jobs to be executed at remote
computational sites. However, very large jobs are often "data
intensive", and in such cases it may be necessary to move the job to
where the data sites are in order to achieve better efficiency.
Alternatively, partial replication of the data can be performed ahead of
time to sites where the computation will take place. Thus, it is
necessary to also support applications that produce and consume large
volumes of data. In reality, most large jobs in the scientific domain
involve the generation of large datasets, the consumption of large
datasets, or both. Therefore, it is essential that software systems
exist that can provide space reservation and schedule the execution of
large file transfer requests into the reserved spaces. Storage Resource
Managers (SRMs) are designed to fill this gap.**

**In addition to storage resources, SRMs also need to be concerned with
the *data resource* (or files that hold the data). A data resource is a
chunk of data that can be shared by more than one client. In many
applications, the granularity of a data resource is a file. It is
typical in such applications that tens to hundreds of clients are
interested in the same subset of files when they perform data analysis.
Thus, the management of shared files on a shared storage resource is
also an important aspect of SRMs. The decision of which files to keep in
the storage resource is dependent on the cost of bringing files from
remote systems, the size of the file, and the usage level of that file.
The role of the SRM is to manage the space under its control in a way
that is most cost beneficial to the community of clients it serves.**

**In general, an SRM can be defined as a middleware component that
manages the dynamic use and content of a storage resource in a
distributed system. This means that space can be allocated dynamically
to a client, and that the decision of which files to keep in the storage
space is controlled dynamically by the SRM. The main concepts of SRMs
are described in \[SSG02\] and subsequently in more detail in a book
chapter \[SSG03\]. The concept of a storage resource is flexible: an SRM
could be managing one or more disk caches, or a hierarchical tape
archiving system, or a combination of these. In what follows, they are
referred to as "storage components". When an SRM at a site manages
multiple storage resources, it may have the flexibility to store each
file at any of the physical storage systems it manages (referred to as
storage components) or even to replicate the files in several storage
components at that site. The SRMs do not perform file transfer, but
rather use file transfer services, such as GridFTP, to get files in/out
of their storage systems. Some SRMs also provide access to their files
through Posix or similar interfaces.**

**SRMs are designed to provide the following main capabilities:**

1)  ***Non-interference with local policies*. Each storage resource can
    > be managed independently of other storage resources. Thus, each
    > site can have its own policy on which files to keep in its storage
    > resources and for how long. The SRM will not interfere with the
    > enforcement of local policies. Resource monitoring and management
    > of both space usage and file sharing that enforce their local
    > policies are the responsibility of SRMs.**

2)  ***Pinning files.* Files residing in one storage component can be
    > temporarily locked in place while used by an application, before
    > being removed for resource usage optimization or transferred to
    > another component. We refer to this capability as *pinning* a
    > file, since a pin is a lock with a *lifetime* associated with it.
    > A pinned file can be actively *released* by a client, in which
    > case the space occupied by the file is made available to the
    > client. SRMs can choose to keep or remove a released file
    > depending on their storage management needs.**

3)  ***Advance space reservations.* SRMs are components that manage the
    > storage content dynamically. Therefore, they can be used to plan
    > the storage system usage by permitting advance space reservations
    > by clients.**

4)  ***Dynamic space management.* Managing shared disk space usage
    > dynamically is essential in order to avoid clogging of storage
    > resources. SRMs use file replacement policies whose goal is to
    > optimize service and space usage based on access patterns.**

5)  ***Support abstract concept of a file name.* SRMs provide an
    > abstraction of the file namespace using "Site URLs" (SURLs), while
    > the files can reside in any one or more of the underlying storage
    > components. An example of an SURL is:
    > srm://ibm.cnaf.infn.it:8444//dteam/test.10193, where the first
    > part "ibm.cnaf.infn.it:8444" is the address and port of the
    > machine where the SRM service is provided, and the second part
    > "/dteam/test.10193" is the abstract file path, referred to as the
    > Site File Name (SFN).**

6)  ***Temporary assignment of transfer file names.* When requesting a
    > file from an SRM, an SURL (see above) is provided. The SRM can
    > have the file in several locations, or can bring it from tape to
    > disk for access. Once this is done a "Transfer URL" (TURL) is
    > returned for a temporary access to the file controlled by the
    > pinning lifetime. A similar capability exists when a client wishes
    > to put a file into the SRM. The request provides the desired SURL
    > for the file, and the SRM returns a TURL for the transfer of the
    > file into the SRM. A TURL must have a valid transfer protocol such
    > as: gsiftp://ibm139.cnaf.infn.it:2811//gpfs/dteam/test.10193. Note
    > that the port 2811 is a GridFTP port.**

7)  ***Directory Management and ACLs.* The advantage of organizing files
    > into directories is well known, of course. However, SRMs provide
    > directory management support to the SURL abstractions and keep the
    > mapping to the actual files stored in the underlying file systems.
    > Accordingly, Access Control Lists (ACLs) are associated with the
    > SURLs.**

8)  ***Transfer protocol negotiation.* When making a request to an SRM,
    > the client needs to end up with a protocol for the transfer of the
    > files that the storage system supports. In general, systems may be
    > able to support multiple protocols and clients should be able to
    > use different protocols depending on the system they are running
    > on. SRM supports protocol negotiation, by matching the highest
    > protocol they can support given an ordered list of preferred
    > protocols by the client.**

9)  ***Peer to peer request support.* In addition to responding to
    > clients requests, SRMs are designed to communicate with each
    > other. Thus, one SRM can be asked to copy files from/to another
    > SRM.**

10) ***Support for multi-file requests*. The ability to make a single
    > request to get, put, or copy multiple files is essential for
    > practical reasons. This requirement is supported by SRMs by
    > specifying a set of files. Consequently, such requests are
    > asynchronous, and status functions need to be provided to find out
    > the progress of the requests.**

11) ***Support abort, suspend, and resume operations*. These are
    > necessary because requests may be running for a long time, in case
    > that a large number of files are involved.**

**The main challenges for a common interface specification are to design
the functionality of SRMs and their interfaces to achieve the goals
stated above, and to achieve the interoperation of SRM implementations
that adhere to the common interface specification. More details of the
basic functionality can be found in \[SSG03\]. The specification of SRM
interfaces and their corresponding WSDL can be found at the SRM
collaboration web site \[srm-collab\].**

**The functions supported by SRMs in order to get files from the SRMs or
put files into the SRMs are referred to as "srmPrepareToGet" and
"srmPrepareToPut". A set of files (or a directory) is provided by the
client in the form of SURLs, and TURLs are returned by the SRM. The
TURLs are used by the requesting clients to get or put files from/into
the SRM using the TURL's transfer protocol. The function srmCopy
provides the capability to replicate files from one SRM to another.**

**When using the space reservation function srmReserveSpace, the client
can specify the desired space and duration of the reservation. The SRM
returns the space and duration it is willing to allocate according to
its policies, and a space token. If the client does not wish to accept
that, it can issue srmReleaseSpace. Otherwise, it can put files into the
reserved space by referring to the space token.**

**Directory functions are very similar to the familiar Unix functions
and include srmLs, srmMkdir, srmRmdir, srmMv, and srmRm. Since files may
have a limited lifetime in the SRM, these functions need to reflect
lifetime status as well.**

1.  []{#_Toc199734412 .anchor}**Additional concepts introduced with
    v2.2**

**Soon after the WLCG collaboration decided to try and adopt version 2.1
of the SRM specification as a standard for all their storage systems, it
became clear that some concepts needed to be clarified, and perhaps new
functionality added. The main issues were: 1) the specification of the
storage properties; 2) the clarification of space and the meaning of a
space token when it is returned after a space reservation is made; and
3) the ability to request that files will be brought from archival
storage into an online disk system for subsequent access. This led to a
new SRM specification, referred to as SRM v2.2, presented in this
document. We discuss each of these concepts further next.**

1.  **Storage component properties**

**The issue of how to expose expected behavior of a storage component by
the SRM was debated at great length. In the end, it was concluded that
it is sufficient to expose two orthogonal properties: Retention Policy
and Access Latency. These are defined below:**

a)  **Retention Policy: REPLICA, OUTPUT, CUSTODIAL**

> **The Quality of Retention is a kind of Quality of Service. It refers
> to the probability that the storage system loses a file. The type is
> used to describe the retention policy assigned to the files in the
> storage system at the moment when the files are written into the
> desired destination in the storage system. It is 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 description of Retention Policy Types is:**

-   **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.**

b)  **Access Latency: ONLINE, NEARLINE**

> **Files may be Online or Nearline. These terms are used to describe
> the latency to access a file. Latency can be improved by storage
> systems by replicating a file from nearline to online storage. We do
> not include here "offline" access latency, since a human has to be
> involved in getting offline storage mounted. For SRMs, one can only
> specify ONLINE and NEARLINE. The type is used to describe an access
> latency property that can be requested at the time of space
> reservation. The files that are contained in the space may have the
> same or lower access latency as the space. The ONLINE cache of a
> storage system is the part of the storage system which provides file
> access with online latencies. The description of Access Latency types
> is:**

-   **ONLINE has the lowest latency possible. No further latency
    improvements can be applied to online files.**

-   **NEARLINE files can have their latency improved to online latency
    automatically by staging the files to online cache.**

    1.  **Storage Areas and Storage Classes**

**Because of fairly complex storage systems used by the WLCG
collaboration, it was obvious that referring to "storage system" is
imprecise. Instead, the concept of a "storage area" is used. A storage
system usually is referred to as a Storage Element, viz. a grid element
providing storage services.**

**A Storage Element can have one or more storage areas. Each storage
area includes parts of one or more hardware components (single disk,
RAID, tape, DVD, ...). Any combination of components is permissible. A
storage area is specified by its properties which include the Access
Latency and Retention Policy described above. Explicitly supported
combinations are known as Storage Classes: online-replica (e.g. a common
disk space allocated for online access), nearline-custodial (e.g. a
high-quality robotic tape system), or online-custodial (e.g. a highly
protected online disk that may keep multiple replicas, or an online disk
with backup on a high-quality robotic tape system). Storage areas that
consist of heterogeneous components are referred to as "composite
storage areas" and the storage space in them as "composite space".
"Composite storage elements" are storage elements serving composite
storage areas. Storage areas can share one or more storage components.
This allows storage components to be partitioned for use by different
user-groups or Virtual Organizations (VOs).**

**The SRM interface exposes only the storage element as a whole and its
storage areas, not their components. However, a space reservation to a
composite storage element can be made requesting Access
Latency-Retention Policy combinations that may determine which storage
components are assigned. Specifically, a space reservation to a
composite storage element can request the following combinations to
target the online or nearline storage components: a) online-replica to
target the online storage components; b) nearline-custodial to target
the nearline storage components (assuming they support custodial
retention policy); c) online-custodial to target both the online and
nearline storage components.**

2.  **The function srmBringOnline**

**When a file is requested from a mass storage system (MSS), it is
brought onto disk from tape in case that the file is not already on
disk. The system determines which files to keep on disk, depending on
usage patterns and system loads. However, this behavior is not always
acceptable to large projects, since they need to be in control of what
is online in order to ensure efficient use of computing resources. A
user performing a large analysis may need to have all the files online
before starting the analysis. Similarly, a person in charge of a group
of analysts may wish to bring all the files for that group online for
all of them to share. Therefore the concept of bringing files online was
introduced.**

**srmBringOnline can be applied only to a composite space that has
nearline as well as online components. When performing this function the
SRM is in full control as to where files end up and this information is
not visible to the client. For example, the SRM may have multiple online
spaces, and it can choose which will be used for each file of the
request. Similarly, the SRM can choose to keep multiple online replicas
of the same file for transfer efficiency purposes. Once srmBringOnline
is performed, subsequent srmPrepareToGet requests can be issued by
clients, and TURLs returned, where each TURL indicates where the
corresponding file can be accessed, and the protocol to be used.**

1.  []{#_Toc199734413 .anchor}**SRM Implementations**

**Over the last 6-7 years, there were several implementations of SRMs.
The first implementations were based on the v1.1 specifications (see
\[srm-collab\]), at several institutions in the US and Europe, including
FNAL, Jlab, LBNL, and CERN. More recently, new implementations to a
variety of storage systems emerged that are based on the richer v2.2
specification described in this document. The underlying storage systems
can vary from a simple disk, multiple disk pools, mass storage systems,
parallel file systems, to complex multi-component multi-tiered storage
systems. While the implementations use different approaches, we
illustrate the power of the SRM standard approach in that such systems
exhibit a uniform interface and can successfully interoperate. While
they adhere to the SRM v2.2 specification, some chose not to support
some of the functionality. For example, some implementations do not
support ACLs. Other implementation to a variety of systems built on top
of innovative and sophisticated file system capabilities, such as SRB
\[srb\] and L-Store \[l-store\] are underway. In addition, two test
programs have been developed and are run daily to check the
interoperability of these systems \[MD'07, srm-tester\]. Current SRM
implementations based on v2.2 specification are described in Appendix I
(in alphabetical order).**

8.  []{#_Toc199734414 .anchor}**Appendix I : Current SRM Implementations
    Based on v2.2 specification**

**Over the last 6-7 years, there were several implementations of SRMs.
The first implementations were based on the v1.1 specifications (see
\[srm-collab\]), at several institutions in the US and Europe, including
Fermilab, Jlab, LBNL, and CERN. More recently, new implementations
emerged that are based on the richer v2.2 specification described in
this document. We mention here five such implementations, in order to
illustrate the ability of SRMs to have the same interface to a variety
of storage systems. The underlying storage systems can vary from a
simple disk, multiple disk pools, mass storage systems, parallel file
systems, to complex multi-component multi-tiered storage systems. While
the implementations use different approaches, we illustrate the power of
the SRM standard approach in that such systems exhibit a uniform
interface and can successfully interoperate. While they adhere to the
SRM v2.2 specification, some chose not to support some of the
functionality. For example, some implementations do not support ACLs.
Other implementation to a variety of systems built on top of innovative
and sophisticated file system capabilities, such as SRB \[srb\] and
L-Store \[l-store\] are underway. In addition, two test programs have
been developed and are run daily to check the interoperability of these
systems \[MD'07, srm-tester\]. The SRMs mentioned below (in alphabetical
order) are fully implemented.**

1.  []{#_Toc199734415 .anchor}**BeStMan -- Berkeley Storage Manager**

**BeStMan is a java-based SRM implementation from LBNL. Its modular
design allows different types of storage systems to be integrated in
BeStMan while providing the same interface for the clients. Based on
immediate needs, two particular storage systems are currently used. One
supports multiple disks accessible from the BeStMan server, and the
other is the HPSS storage system. Another storage system that was
adapted with BeStMan is a legacy MSS at NCAR in support of the Earth
System Grid project (www.earthsystemgrid.org).**

**BeStMan supports space management functions and data movement
functions. Users can reserve space in the preferred storage system, and
move files in and out of their space. When necessary, BeStMan interacts
with remote storage sites on their behalf, e.g. another gridftp server,
or another SRM. BeStMan does not support ACLs.**

2.  []{#_Toc199734416 .anchor}**Castor-SRM**

**The SRM implementation for the CERN Advanced Storage system (CASTOR)
is the result of collaboration between Rutherford Appleton Laboratory
(RAL) and CERN. Like that of other implementations, the implementation
faced unique challenges. These challenges were based around the
fundamental design concepts which CASTOR operates under, which are
different from those of other mass storage systems. CASTOR trades some
flexibility for performance, and this requires the SRM implementation to
have some loss of flexibility, but with gains in performance.**

**CASTOR is designed to work with a tape back-end and is required to
optimise data transfer to tape, and also to ensure that data input to
front-end disk cache is as efficient as possible. It is designed to be
used in cases where it is essential to accept data at the fastest
possible rate and have that data securely archived. These requirements
are what cause differences between the CASTOR SRM implementation and
others.**

**Space management in the CASTOR SRM is significantly different to those
of other implementations. Since the design of the MSS is to optimise
moving data from disk to tape, there is no provision for allowing
dynamic space allocation at a user level. The CASTOR SRM does support
space reservation, but as an asynchronous process involving physical
reallocation of the underlying disk servers.**

3.  []{#_Toc199734417 .anchor}**dCache-SRM**

**dCache \[dcache\] is a Mass Storage System developed jointly by FNAL
and DESY which federates a large number of disk systems on heterogeneous
server nodes to provide a storage service with a unified namespace.
dCache provides multiple means of file access protocols, including FTP,
Kerberos GSSFTP, GSIFTP, HTTP, GSIDcap, dCap, xrootd \[xrootd\], and
POSIX APIs to dCache. dCache can act as a stand-alone Disk Storage
System or as a front-end disk cache in a hierarchical storage system
backed by a tape interface such as OSM, Enstore \[enstore\], Tsm, HPSS
\[hpss\], DMF or CASTOR \[castor\]. dCache storage system has a highly
scalable distributed architecture that allows easy addition of new
services and data access protocols.**

**dCache provides load balancing and replication across nodes for "hot"
files, i.e. files that are accessed often. It also provides a resilient
mode, which guarantees that a specific number of copies of each file are
maintained on different hardware. This mode can take advantage of
otherwise unused and unreliable disk space on compute-nodes. This is a
cost-effective means of storing files robustly and maintaining access to
them in the face of multiple hardware failures.**

4.  []{#_Toc199734418 .anchor}**DPM -- Disk Pool Manager**

**The DPM (Disk Pool Manager) aims at providing a reliable and managed
disk storage system, including multiple disk pools. The architecture is
based on a database and multi-threaded daemons. It supports gsiftp,
rfio, https and xrootd \[xrootd\] protocols.**

**A database backend (both MySQL and Oracle are supported) is used as a
central information repository. It contains two types of information: 1)
Data related to the current DPM configuration (pool and file system) and
the different asynchronous requests (get and put) with their statuses.
This information is accessed only by the DPM daemon. The SRM daemons
only put the asynchronous requests and poll for their statuses. 2) Data
related to the namespace, file permissions (ACLs included) and virtual
IDs which allow a full support of the ACLs. Each user DN (Distinguished
Name) or VOMS (Virtual Organization Membership Service) \[voms\]
attribute is internally mapped to an automatically allocated virtual
ID.**

5.  []{#_Toc199734419 .anchor}**StoRM - Storage Resource Manager**

**StoRM (acronym for Storage Resource Manager) is an SRM service
designed to manage file access and space allocation on high performing
parallel and cluster file systems as well as on standard POSIX file
systems. The StoRM project is the result of the collaboration between
INFN -- the Italian National Institute for Nuclear Physics - and the
Abdus Salam ICTP for the EGRID Project for Economics and Finance
research.**

**StoRM is designed to respond to a set of requests coming from various
Grid applications allowing for standard POSIX access to files in local
environment, and leveraging on the capabilities provided by modern
parallel and cluster file systems such as the General Parallel File
System (GPFS) from IBM. The StoRM service supports guaranteed space
reservation and direct access (by native POSIX I/O calls) to the storage
resource, as well as supporting other standard Grid file access
libraries like RFIO and GFAL.**

9.  []{#_Toc199734420 .anchor}**Appendix II : WLCG use case**

[]{#_Toc199734421 .anchor}**Introduction**

The European research centre CERN currently builds the Large Hadron
Collider (LHC) to allow for the study of elementary particles and forces
at the highest energy densities ever obtained in a laboratory. The LHC
will support four experiments that are expected to produce roughly 15
Petabytes (15 million Gigabytes) of data annually, which thousands of
scientists around the world will access and analyze. The mission of the
Worldwide LHC Computing Grid Project (WLCG) is to develop, build and
maintain a computing infrastructure for storage and analysis of the LHC
data. Data will be distributed around the globe according to a
four-tiered model. A primary backup will be recorded at CERN, the
\"Tier-0\" centre of WLCG. After initial processing, these data will be
distributed to a series of Tier-1 centers, large computer centers with
sufficient compute and storage capacities as well as round-the-clock
support for Grid operations. The Tier-1 centers will perform recurrent
reconstruction passes and make data available to Tier-2 centers, each
consisting of one or several collaborating computing facilities, which
can store sufficient data and provide adequate computing power for
specific analysis tasks. Individual scientists will access these
facilities through Tier-3 computing resources, which can consist of
local clusters in a University Department or even individual PCs
\[WLCG-INTRO\].

The WLCG had to deal with multiple storage systems and using the SRM
concept of a uniform layer on top of these storage systems is appealing.
A decision was made to adopt the SRM v2.2 specification, as well as to
contribute to its enhancement in terms of functionality and clarity of
the specification. These enhancements are reflected in this document. It
was also decided that test programs will be developed to check the
adherence of various implementations to the SRM v2.2 specification, as
well as the interoperability of the implementations. Several
implementations have been developed as well as test suites and were
recently reported in the Mass Storage Systems and Technologies
conference \[MSST 2007\].

In order to meet the timescale for LHC experiments' requirements for
grid storage, the WLCG has had to agree on certain restrictions and
interpretations of the SRM v2.2 specification. This Appendix specifies
the server behavior for the SRM v2.2 implementations used by WLCG
applications. It specifies how the various existing methods and data
objects, as they are specified in the agreed v2.2 specification, should
be used in order meet the WLCG requirements. The outlined WLCG
interpretation of the interfaces is somewhat more restrictive than other
implementations of SRM client and servers, although care is taken to
preserve interoperability with the latter.

1.  []{#_Toc199734422 .anchor}**Storage classes**

One of the concepts that need to be supported for large storage systems
is how to interpret storage of files in systems that have both tape and
disk storage. The descriptive behavior often refers to that as "how many
copies are kept on tape and how many on disk. The label **"TapeXDiskY"
was used to express X copies on tape and Y copies on disk. In practice,
X and Y assume values of 0 or 1, and rarely 2 (2 copies for storing
invaluable data). There was a need to map these concepts to the more
general features of Access Latency and Retention Policy in the SRM
specification. This is described next.**

**Wherever usage of storage class argument is agreed to be required by
WLCG, the agreed terminology is:**

-   **TAccessLatency {ONLINE, NEARLINE}**

-   **TRetentionPolicy {REPLICA, CUSTODIAL}**

**The "OUTPUT" value of the TRetentionPolicy as well as the "OFFLINE"
value of the *TAccessLatency* shall *not*be used by any WLCG
application. The mapping to labels is given by:**

-   **Tape1Disk0: NEARLINE + CUSTODIAL**

-   **Tape1Disk1: ONLINE + CUSTODIAL**

-   **Tape0Disk1: ONLINE + REPLICA**

**WLCG clients shall only use those three combinations of
*TAccessLatency* and *TRetentionPolicy*. In all subsequent methods
listed in the following, the allowed/disallowed usage of storage classes
attributes is specified as needed.**

1.  []{#_Toc199734423 .anchor}**Removal policies**

All WLCG files are "permanent" meaning that any implicit automatic
removal of the file from the storage system is disallowed. The file
lifecycle within an SRM is always terminated by the user calling the
*srmRm* method.

2.  []{#_Toc199734424 .anchor}**Protocol negotiation**

The protocols are specified in the preferred order on all SRM transfer
functions (*srmPrepareToGet*, *srmPrepareToPut*, *srmBringOnline*).

3.  []{#_Toc199734425 .anchor}**Information discovery**

-   There is no requirement for an SRM information interface for WLCG
    production.

-   Client implementations provide list of required information.

-   GLUE WG \[glue-wg\] defines an external information system schema
    accordingly.

-   In the longer term, implementations may provide the interface to
    query for the information required for the GLUE schema.

    1.  []{#_Toc199734426 .anchor}**srmReserveSpace**

For practical use of WLCG,*srmReserveSpace* only deals with space
reservations on disk cache while tape space is always considered
infinite. SRM implementations may allow dynamic space reservations for
any user while other implementations may only allow static reservations
restricted for use by certain VO (Virtual Organization) roles. For
static reservations, detailed requirements for the reservation, like
network connectivity, may be negotiated directly between storage
provider and client.

-   WLCG clients shall only specify *desiredSizeOfGuaranteedSpace* while
    *desiredSizeOfTotalSpace* shall be ignored by all WLCG servers.

-   WLCG server implementations are allowed to restrict permission to
    reserve space to certain VO roles. The WLCG client shall handle the
    corresponding error: SRM\_AUTHORIZATION\_FAILURE.

-   The *arrayOfExpectedFileSizes* shall not be used.

-   If the requested *retentionPolicyInfo* cannot be satisfied,
    SRM\_INVALID\_REQUEST error code shall be returned.

-   WLCG clients shall not specify *storageSystemInfo*, and servers
    shall ignore any value provided in this parameter.

-   SRM implementation may return infinite lifetime no matter what was
    specified by the user. It is then the client's responsibility to
    remove the space.

-   WLCG clients shall use *srmGetSpaceTokens* method with the user
    space description to get to the space token.

-   WLCG clients shall not use dynamic space reservations initially.

    1.  []{#_Toc199734427 .anchor}**srmChangeSpaceForFiles**

The common use case for this method is the transition of Tape1Disk1
-\>Tape1Disk0 or vice versa (both supported in WLCG), or change of
retention policy Tape0Disk1 -\>Tape1Disk\[0-1\] or vice versa (neither
supported in WLCG).

-   *srmChangeSpaceForFiles* is asynchronous.

-   For any transition forbidden by the SRM implementation, an error
    SRM\_INVALID\_REQUEST is returned to the client.

-   *srmChangeSpaceForFiles* is not required for the start LHC
    production but is needed later.

-   WLCG SRM implementations shall not change the SURL when a file is
    moved to a new space.

-   The signature of *srmStatusOfChangeSpaceForFilesRequest* remains to
    be discussed between the SRM implementers.

-   **WLCG SRM implementations and clients shall decide which
    transitions should be supported.**

    1.  []{#_Toc199734428 .anchor}**srmPurgeFromSpace**

Purges files from the given space. The difference from*srmReleaseFiles*
and *srmAbortFiles* is that *srmPurgeFromSpace* is not associated with a
request. *srmReleaseFiles* is enhanced with a flag "*doRemove*" giving a
hint for the immediate garbage collection of disk copies.

-   If the specified space contains the only remaining copy of the file
    in the storage system, an error SRM\_LAST\_COPY is returned.

-   The method shall only succeed if there are no outstanding pins or
    requests for the specified files. Otherwise an error SRM\_FILE\_BUSY
    is returned.

    1.  []{#_Toc199734429 .anchor}**srmRm**

Removes name space entry and all associated copies of the file.

2.  []{#_Toc199734430 .anchor}**srmLs**

WLCG clients use *srmLs* for getting metadata attributes of individual
files. Support for directory listings can be motivated for
cross-checking file catalogues.

-   *TFileLocality* {ONLINE, NEARLINE, ONLINE\_AND\_NEARLINE, LOST,
    NONE, UNAVAILABLE} attribute of the *srmLs* output shall be
    supported for individual file queries but not for directory
    listings, even when a detailed directory listing has been requested
    by the client.

-   *spaceToken* attribute of the *srmLs* output shall be supported for
    individual file queries but not for directory listings, even when a
    detailed directory listing has been requested by the client.

-   The "LOST" value of *TFileLocality* shall be used if the file is
    lost because of a permanent hardware failure. The "NONE" value shall
    be used if the file is empty (zero size). The "UNAVAILABLE" value
    shall be used if the file is unavailable due to temporary hardware
    failure.

-   For directory listings,*srmLs* output may be constrained to an upper
    limit on the number of entries returned.

-   *srmLs* for a non-existing file or directory shall result in an
    SRM\_INVALID\_PATH error

-   If *numberOfLevels* is specified to be zero, the returned
    information shall be for the directory itself and not for the files
    in the directory.

Support for *offset* and *count* in the *srmLs* function at the
timescale for LHC production will require more discussion. Currently no
WLCG implementation supports it.

1.  []{#_Toc199734431 .anchor}**srmPrepareToGet**

*srmPrepareToGet* is used for preparing a file for transfer or access.
WLCG usage excludes the usage of *srmPrepareToGet* for changing space or
retention attributes of the file.

-   WLCG tools/clients shall not use space tokens, or retention
    policy/access latency on a *srmPrepareToGet.*

-   *transferParameters* for transfer protocols is a required input
    parameter.

-   *srmPreparetToGet* is asynchronous.

-   It is up to the storage system to decide the *TConnectionType*of
    *TTransferParameters*if not provided.

-   WLCG clients shall not have expectations of any value returned for
    the *estimatedWaitTime*.

-   If any of the requested files is temporarily unavailable (e.g. due
    to hardware failure), an error SRM\_FILE\_UNAVAILABLE is returned
    for that file.

-   If any of the requested files is permanently lost (e.g. due to
    hardware failure), an error SRM\_FILE\_LOST is returned for that
    file.

-   The SRM implementation should fail with an error SRM\_FILE\_BUSY for
    a file for which there is an active *srmPrepareToPut* (no
    *srmPutDone*is yet called).

-   If the request does not complete within the
    *desiredTotalRequestTime*, the request will fail with SRM\_TIMEDOUT.
    The *desiredTotalRequestTime* can be negotiated with the SRM
    implementation. This functionality is desired for the longer term
    but *not*required for the start of LHC production.

-   The WLCG SRM implementations shall allow an *srmPrepareToGet*
    request to continue, provided that at least one file is successful
    or in progress.

    1.  []{#_Toc199734432 .anchor}**srmBringOnline**

```{=html}
<!-- -->
```
-   *srmBringOnline* is asynchronous.

-   Transfer protocol matching shall work like for *srmPrepareToGet*.

-   The *deferredStartTime*input parameter means that the client does
    not intend to use the files before that time. The purpose is to be
    able to support CE -- SE resource co-allocations and tape mounting
    efficiency.

-   WLCG tools/clients shall not use *targetSpaceToken* or
    *targetFileRetentionPolicyInfo* on a *srmBringOnline*.

-   If the transfer protocol list in *transferParameters*is not
    specified, the default is assumed to be the {PROCESSING\_MODE, LAN}
    for the *TAccessPattern* and *TConnectionType*. WLCG clients are
    strongly recommended to specify the transfer protocols.

-   It is up to the storage system to decide the *TConnectionType* if
    not provided.

-   WLCG clients shall not have expectations of any value returned for
    the *estimatedWaitTime*.

-   If any of the requested files is temporarily unavailable (e.g. due
    to hardware failure), an error SRM\_FILE\_UNAVAILABLE is returned
    for that file.

-   If any of the requested files is permanently lost (e.g. due to
    hardware failure), an error SRM\_FILE\_LOST is returned for that
    file.

-   The SRM implementations should fail with an error SRM\_FILE\_BUSY
    for a file for which there is an active *srmPrepareToPut* (no
    *srmPutDone*is yet called).

-   If the request does not complete within the
    *desiredTotalRequestTime*, the request will fail with SRM\_TIMEDOUT.
    The *desiredTotalRequestTime* is negotiated with the SRM
    implementation. This functionality is desired for the longer term
    but *not*required for the start of LHC production.

-   The WLCG SRM implementations shall allow an *srmBringOnline* request
    to continue provided that at least one file is successful or in
    progress.

    1.  []{#_Toc199734433 .anchor}**srmPrepareToPut**

```{=html}
<!-- -->
```
-   *transferParameters* for transfer protocol is a required input
    parameter.

-   *srmPreparetToPut* is asynchronous.

-   It is up to the storage system to decide the *TConnectionType*of
    *TTransferParameters*if not provided.

-   WLCG clients shall not have expectations of any value returned for
    the *estimatedWaitTime*.

-   *transferProtocolInfo*of *TPutRequestFileStatus* output parameter
    will initially not be supported for WLCG production.

-   The WLCG client shall provide *targetSURL*s as input parameters, and
    hence SRM implementations are not required to generate names.

-   If the request does not complete within the
    *desiredTotalRequestTime*, the request will fail with SRM\_TIMEDOUT.
    The *desiredTotalRequestTime* is negotiated with the SRM
    implementation. This functionality is desired for the longer term,
    but *not*required for the start of LHC production.

-   The WLCG SRM implementations shall allow an *srmPrepareToPut*
    request to continue, provided that at least one file is successful
    or in progress.

-   If both *targetSpaceToken* and *targetFileRetentionPolicyInfo* are
    provided, the retention policy attribute must match that of the
    specified space. Otherwise the request fails with
    SRM\_INVALID\_REQUEST.

-   WLCG clients shall use the *targetSpaceToken,*but*not*the
    *targetFileRetentionPolicyInfo*. If the *targetSpaceToken* is not
    provided, a default space will be chosen by the SRM.

-   For non-WLCG implementations, *desiredFileLilfetime* for SURL shall
    not be used by WLCG clients, and WLCG SRM implementations are not
    required to support it.

-   The *desiredPinLifetime* for TURL is the allowed time during which
    the file may be written; there is no guarantee as to the
    availability of the TURL for writing after this time.

-   A TURL returned by *srmPrepareToPut* may not be used for read access
    with any protocols. An explicit *srmPrepareToGet* call is required.

-   The SRM implementation should fail with an error SRM\_FILE\_BUSY for
    a file for which there is an active *srmPrepareToPut* (no
    *srmPutDone*is yet called).

    1.  []{#_Toc199734434 .anchor}**srmCopy**

```{=html}
<!-- -->
```
-   The *dirOption*in *TCopyFileRequest* will not be supported
    initially.

-   The *desiredTargetSURLLifetime*shall not be used by WLCG clients,
    and WLCG SRM implementations are not required to support it.

-   Files are immutable. WLCG clients shall not specify
    *overwriteOption*. If SRM returns failure, the state of the system
    shall be as if the file transfer did not take place.

-   If the request does not complete within the
    *desiredTotalRequestTime*, the request will fail with SRM\_TIMEDOUT.
    The *desiredTotalRequestTime* is negotiated with the SRM
    implementation. This functionality is desired for the longer term
    but *not*required for the start of LHC production.

-   WLCG clients shall use the *targetSpaceToken* and *not*the
    *targetFileRetentionPolicyInfo*. If the *targetSpaceToken* is not
    provided, a default space will be chosen by the SRM.

-   The SURLs passed in a call to the *srmAbortFiles* method following
    an*srmCopy* are the target SURLs, which are bound to be unique.

-   The SRM implementation should fail with an error SRM\_FILE\_BUSY for
    a file for which there is an active srmPrepareToPut (no srmPutDone
    is yet called), considering both source and target.

10. []{#_Toc199734435 .anchor}**Contributors**

Authors of this document are people who have been involved in SRM
specfication over the years. The author list includes, by institution,
on the first page of this document.

11. []{#_Toc199734436 .anchor}**Acknowledgement**

This document 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.This work is also co-funded by the European Commission
through the EGEE-II project, contract number INFSO-RI-031688.

12. []{#_Toc199734437 .anchor}**Copyright Notice**

© Copyright Lawrence Berkeley National Laboratory (LBNL), Fermi National
Accelerator Laboratory (FNAL), Thomas Jefferson National Accelerator
Facility (TJNAF), 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, 2008.
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, Thomas Jefferson
National Accelerator Facility, Rutherford Appleton Laboratory,
**Istituto Nazionale di Fisica Nucleare, International Centre for
Theoretical Physics** 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.

13. []{#_Toc199734438 .anchor}**OGF Disclaimer**

This document and the information contained herein is provided on an "As
Is" basis and the OGF disclaims all warranties, express or implied,
including but not limited to any warranty that the use of the
information herein will not infringe any rights or any implied
warranties of merchantability or fitness for a particular purpose.

14. []{#_Toc199734439 .anchor}**OGF Intellectual Property Statement**

The OGF takes no position regarding the validity or scope of any
intellectual property orother rights that might be claimed to pertain to
the implementation or use of thetechnology described in this document or
the extent to which any license under suchrights might or might not be
available; neither does it represent that it has made any effortto
identify any such rights. Copies of claims of rights made available for
publicationand any assurances of licenses to be made available, or the
result of an attempt made toobtain a general license or permission for
the use of such proprietary rights byimplementers or users of this
specification can be obtained from the OGF Secretariat.

The OGF invites any interested party to bring to its attention any
copyrights, patents orpatent applications, or other proprietary rights
which may cover technology that may berequired to practice this
recommendation. Please address the information to the OGFExecutive
Director.

15. []{#_Toc199734440 .anchor}**OGF Copyright Notice**

Copyright (C) Open Grid Forum (2007,2008). All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the OGF or other organizations, except as needed for
the purpose of developing Grid Recommendations in which case the
procedures for copyrights defined in the OGF Document process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the OGF or its successors or assignees.

16. []{#_Toc199734441 .anchor}**References**

**\[castor\] http://castor.web.cern.ch/castor/**

**\[dcache\] http://www.dcache.org/**

**\[enstore\] http://www-ccf.fnal.gov/enstore/**

**\[esg\] http://www.earthsystemgrid.org/**

**\[jasmine\] The design and evolution of Jefferson lab's Jasmine mass
storage system, B.K. Hess, M. Haddox-Schatz, M.A. Kowalski, Proceedings
of 13th NASA Goddard Conference on Mass Storage Systems, April 2005.**

**\[glite\] http://glite.web.cern.ch/glite/**

**\[glue-wg\] http://forge.ogf.org/sf/projects/glue-wg**

**\[hpss\] http://www.hpss-collaboration.org/hpss/index.jsp**

**\[ISGC2007\] A Model for the Storage Resource Manager, A. Domenici, F.
Donno, International Symposium on Grid Computing (ISGC 2007),
http://event.twgrid.org/isgc2007/program.htm**

**\[l-store\] www.lstore.org/index.php**

**\[MD'07\] The S2 testing suite, J. Mencak, F. Donno,
http://s-2.sourceforge.net**

**\[MSST2007\] Storage Resource Managers: Recent International
Experience on Requirements and Multiple Co-Operating Implementations,
MSST 2007: 47-59**

**\[srb\] http://www.sdsc.edu/srb/index.php/Main\_Page**

**\[srm-tester\] SRM Storage Tests and Monitoring,
http://datagrid.lbl.gov/**

**\[srm-collab\] http://sdm.lbl.gov/srm-wg**

**\[SSG02\] Storage Resource Managers: Middleware Components for Grid
Storage, A. Shoshani, A. Sim, J. Gu, Nineteenth IEEE Symposium on Mass
Storage Systems, 2002**

**\[SSG03\] Storage Resource Managers: Essential Components for the
Grid, Arie Shoshani, Alexander Sim, and Junmin Gu, in Grid Resource
Management: State of the Art and Future Trends, Edited by Jarek
Nabrzyski, Jennifer M. Schopf, Jan weglarz, Kluwer Academic Publishers,
2003**

**\[storm\] http://storm.forge.cnaf.infn.it/**

**\[voms\] The Virtual Organization Membership Service,
http://www.globus.org/grid\_software/security/voms.php**

**\[WLCG-INTRO\] largely** quoted from
http://www.fzk.de/fzk/idcplg?IdcService=FZK&node=2899&lang=en

**\[wlcg-collab\] http://cerncourier.com/cws/article/cern/29856**

**\[xrootd\] http://xrootd.slac.stanford.edu/**

**\[XSDDATE\]
http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/\#dateTime**