Integration of migration level two and backup tape processing using multiple inventory entries

We claim:

1. In a computer system with at least one data processor and a hierarchically organized data storage system having at least a first, relatively high level data storage facility connected to the data processor for storing data for access by the data processor, and a second, relatively low level data storage facility connected to the data processor for storing repository versions of the data to support an auxiliary storage function including at least one of the backup, archival, and migration of the data, a computer-executable method for storing data in the low level data storage facility, the method comprising the steps of:

providing a single inventory describing the contents of the low level data storage facility for all of the auxiliary storage functions;

generating a repository version of the data to support a first auxiliary storage function and storing the repository version in the low level data storage facility; and

creating and entering in the single inventory a first entry for the repository version, the first entry including:

an object identifier portion indicating a storage location in the low level data storage facility where the repository version is stored; and

a function entry portion identifying the repository version, the first auxiliary storage function, and the object portion.

2. The method of claim 1 further including the step of creating and entering into the single inventory a second entry for the repository version, the second entry including a function portion identifying the data, a second auxiliary storage function, and the object portion.

3. The method of claim 1 wherein the step of storing the repository version further includes the step of storing the repository version on a data storage medium which is removable from the low level data storage facility.

4. In a computer system with at least one data processor and a hierachrically organized data storage system having at least a first, relatively high level of data storage connected to the data processor and a second, relatively low level of data storage connected to the data processor, a method for storing data, the method comprising the computer-executable steps of:

maintaining a single inventory describing the contents of the second level of data storage;

storing a first version of data in the first level of data storage for access by the at least one data processor;

creating one or more second versions of the data from the first version for a repository function including migration, backup or archiving of the first version and storing the one or more second versions in the second level of data storage;

creating one or more data object identifiers, each uniquely identifying a respective second version of the data created from the first version, identifying the repository function for the one or more second version, and indicating a storage location in the second level of data storage where the second version is stored; and

entering the one or more data object identifiers in the single inventory.

5. A method for storing data as set forth in claim 4 wherein the step of storing the one or more second versions further includes the step of storing data on a data storage medium which is removable from the second level of data storage.

6. A system for storing data, comprising:

a hierarchically organized data storage facility having at least a first, relatively high level data storage apparatus and a second, relatively low level data storage apparatus;

data processor means connected to the data storage facility for processing a primary version of data in the first level data storage apparatus; wherein

the data processor means is connected to the second level data storage apparatus and includes

storage management means for generating second versions of data stored in the first level data storage apparatus in order to migrate, backup and archive the data; and

single inventory means connected to the storage management means for specifying for each second version stored in the second data storage apparatus a storage location where the version is stored and one or more functions for which the second version is stored, such functions including one or more of migration, backup and archiving.

7. An apparatus for storing data comprising:

data processor means for processing data;

a hierarchically organized data storage system having at least a first, relatively high level data storage apparatus connected to the data processor means and a second, relatively low level data storage apparatus connected to the data processor means for storing a secondary version of data having a secondary storage purpose comprising at least one of the backup, archival, and migration of data;

a primary version of data stored in the first storage apparatus for access by the at least one data processor;

a secondary version of data created from the primary version;

a single inventory listing all data stored in the second storage apparatus;

a data object identifier uniquely identifying the secondary version; and

one or more inventory entries for the secondary version, each of said one or more inventory entries including the data object identifier, specifying one or more secondary storage functions applied to the secondary version, and specifying one or more second data storage apparatus locations where the secondary version is stored.

8. A data storage management system, including:

backup means for copying data to a data storage medium to create a backup version of the data;

archive means for copying the data to a data storage medium to create an archive version of the data;

migration means for moving the data to a data storage medium to create a migrated version of the data; and

single inventory means connected to the backup means, the archive means, and the migration means for:

retaining a data storage medium storage location of at least one of the backup, archive, and migrated versions of the data; and

indicating storage of one of the backup, archive, and migrated versions of the data

for one or more of the functions of backup, archive and migration of the data.

9. The data storage management system of claim 8, wherein the single inventory means retains only a single storage medium location of only one of the backup, archive, or migration versions of the data.

10. The data storage management system of claim 8 wherein the single inventory means retains any of the storage medium locations for the backup, archive, or migration versions of the data.

11. A method for storing data in a hierarchical data storage system including an auxiliary storage facility in which data is stored for auxiliary storage purposes including migration, backup, and archiving, the method including the computer-executed steps of:

maintaining a single auxiliary storage inventory describing the contents of the auxiliary storage facility;

generating a version of data for a first auxiliary storage function;

storing the version at an auxiliary storage location in an auxiliary storage medium;

generating a first inventory entry for the version, which includes:

a first object portion identifying the data and the auxiliary storage location; and

a second object portion identifying the data, the first object portion, and the first auxiliary storage function;

entering the first inventory entry into the auxiliary storage inventory;

generating a second inventory entry for the version, which includes a third object portion identifying the data, the first object portion, and a second auxiliary storage function; and

entering the second inventory entry into the auxiliary storage inventory.

12. The method of claim 11, including:

providing a request for the version of data for the first auxiliary storage purpose, the request including identification of the data;

locating the second object portion in the auxiliary storage inventory in response to the request, and retrieving a copy of the version from the auxiliary storage location in response to identification of the data; and

deleting the second object portion from the auxiliary storage facility.

13. The method of claim 12, including:

providing a request for the version of data for the second auxiliary storage function, the request including identification of the data;

locating the third object portion in the auxiliary storage inventory in response to the request, and retrieving a copy of the version in response to identification of the data; and

deleting the third object portion from the auxiliary storage facility.

14. The method of claim 13, further including the step of deleting the first object portion from the auxiliary storage inventory.

15. The method of claim 11, including:

providing a request for the version of data for the second auxiliary storage function, the request including identification of the data;

locating the third object portion in the auxiliary storage inventory in response to the request, and retrieving a copy of the version in response to identification of the data; and

deleting the third object portion from the auxiliary storage facility.

16. The method of claim 15, including:

providing a request for the version of data for the first auxiliary storage function, the request including identification of the data;

locating the second object portion in the auxiliary storage inventory in response to the request, and retrieving a copy of the version from the auxiliary storage location in response to identification of the data; and

deleting the second object portion from the auxiliary storage facility.

17. The method of claim 16, further including the step of deleting the first object portion from the auxiliary storage inventory.

Description Submit all comments and votes

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates generally to computer data storage management, and more specifically to techniques for the backup, archiving, recovery, and/or restoration of Migration Level Two (ML2) tape files.

2. Description of the Prior Art

Present-day computer data processing systems generally include a host processor having one or more central processing units. The host processor is supported by memory facilities and input/output (I/O) interfaces. One or more buses are often employed to provide interconnections between the various components of a computer data processing system.

The processing units execute instructions which specify the manipulation of data stored within the memory facilities. Therefore, the memory facilities must be capable of storing data required by the processor and transferring that data to the processor at a rate capable of making the overall operation of the computer feasible. The cost and performance of computer memory is thus critical to the commercial success of a computer system.

As computers manipulate ever-increasing amounts of data, they require larger quantities of data storage capacity. A typical data processing system includes both main memory and one or more peripheral storage devices. A data processing system having a plurality of peripheral storage devices arranged hierarchically is referred to as a data storage hierarchy.

In a data storage hierarchy, the term "primary data storage" refers to the data storage level having the highest level of performance and the lowest level of storage capacity. The primary data storage level is oftentimes referred to as "level 0" data storage. Secondary, or level 1, storage includes storage capacity equal to or greater than level 0 storage, but at reduced cost and performance. Similarly, level 2 data storage (also referred to as "auxiliary storage") has lower cost and performance than level 1 storage. However, level two storage includes a storage capacity equal to or greater than level 1 storage. Level two storage is often implemented using magnetic tape data storage drives. Data are accessed from these drives by means of relatively cumbersome mechanical tape mounting operations.

Various techniques have been developed to provide computer file data storage management. Storage management may be defined as the manipulation of a data storage hierarchy to balance system performance, data storage, and cost. A storage management system moves and copies data between different levels of the hierarchy to perform these balancing functions. The manipulation of the hierarchy may involve operations such as the deletion of data which are no longer being used.

Storage management includes several subcomponents, such as performance management, capacity management, space management, and availability management. Each of these subcomponents may involve the transfer of data between different levels of the hierarchy. Space management is the movement of data between different levels of the hierarchy so as to store data only in the most appropriate level of the peripheral storage hierarchy. For example, relatively active data should be stored in a relatively high performance level of the hierarchy, and relatively inactive data should be stored within a relatively low performance, low cost level of the hierarchy.

As data age, they are generally referenced less and less. Since such data are relatively less active, they should be moved to a lower performance level of the data storage hierarchy. The movement of data from one level of a data storage hierarchy to another is referred to as "migration", and may include data compression techniques to conserve data storage space. Transferring a file by migration may include the maintenance of a primary copy of a file in level 0 storage. The primary copy is, however, an empty file. The data in the file have already been transferred to the secondary copy of the file in level 1 storage.

Availability management is the backup of data within a data storage hierarchy to improve the likelihood of the data being available if and when they are needed by the host processor. The original or primary copy off the data is not deleted; an additional copy is generated and transferred to another portion of the data storage hierarchy. The secondary copy is typically stored on a different peripheral storage device from the primary copy to ensure the availability of the data. If the primary copy of the data is rendered unavailable, such as by device failure, the secondary copy of the data may still be referenced. The secondary copy of the data need not be stored in a different level of the data storage hierarchy, but this may nevertheless be desirable because the secondary copy is not likely to be as active as the primary copy.

Storage management has traditionally been performed manually. The owner of the data decides when to migrate or back up data, and where such migrated and backup files should be stored. Such decisions are time consuming, usually requiring a review of each file stored. The operations involved are often so intensive that manual reviews and decisions are not made until there is no alternative. For instance, a system user might not migrate any files to level 1 storage until all storage space in level 0 storage is filled. In large systems, or in any system storing relatively large amounts of data, it is simply impractical to perform manual data storage management.

In recent years, computer software has been developed to provide automated data storage management, thereby reducing the need for manual operations. One example of such a management system is the IBM Data Facility Storage Management Sub-System for Virtual Machines software package, hereinafter referred to as "DFSMS/VM". DFSMS/VM software is available from the International Business Machines (IBM) Corporation of Armonk, N.Y. DFSMS is a trademark of the IBM Corporation.

Systems such as DFSMS/VM commonly provide a function for backing up (archiving) data on a magnetic tape data storage drive. However, a function for optimizing space management on a magnetic tape storage drive is seldom offered. For example, one space management system providing for the migration of data is known as the migration level two (ML2) system. ML2 utilizes magnetic tape data storage drives to provide data storage at a hierarchical position of level 2. ML2 capability has only been offered in a select few software data storage management systems, including the IBM Data Facility Hierarchical Storage Manager system (DFHSM), which is a utility to the IBM Multiple Virtual Storage (MVS) series of software operating systems. DFHSM and MVS are available from the International Business Machines Corporation of Armonk, N.Y. DFSHM is a trademark of the IBM Corporation.

Although the use of ML2 data management techniques results in enhanced space management efficiency, prior art data management software systems are not without drawbacks. For instance, these software systems require relatively frequent tape mounting operations. Tape mounts are costly in terms of response time and installation resource commitment. As a practical matter, tape mounts must be carefully controlled, and should be avoided if at all possible.

If it is desired to provide a backup copy of data stored in ML2 level, presently existing software requires a tape drive mount to bring the data back into primary storage, and possibly a second tape mount to put the data into a backup repository. Furthermore, prior art software does not provide for any backups of files which have been migrated to tape. Prior art approaches resolve this problem by providing a tape dual copy function for the ML2 physical tape volumes. However, this resolution does not protect against loss of the primary file due to device failure or accidental erasure.

An additional drawback of prior art migration software relates to the recovery of a migrated file. It is undesirable to recover a migrated file to the primary storage area. An attempt to restore data back to the primary storage area may fail, because migration schemes permit the primary storage area to become overcommited. Furthermore, if the primary storage area had not become overcommited, there would have been no reason to migrate the file in the first place.

Prior art migration techniques do not optimally exploit design features which offer the potential for improved performance and simplicity. More specifically, many of the same processing steps are employed to implement the functions of managing the migration inventory/repository and managing the backup inventory/repository. Existing systems effectively execute the same steps twice: once for migration, and once for backup. No existing system attempts to consolidate these steps into a unified, more efficient operation. As a result, the migration and backup repositories are situated on separate tape volumes. Similarly, the migration and backup inventories are also segregated.

Presently-existing methods of performing an archive of a file that is migrated to ML2 tape require numerous processing steps. First, a recall of the file must be accomplished. This requires a tape mount, data movement from the ML2 tape repository back to primary storage, and updating the associated inventory. Next, the data are archived. The step of archiving the data involves three sub-steps. First, another tape mount must be provided. Second, data must be moved in order to place the required data on the archive (or backup) repository. Third, the associated inventory must be updated. After archival, the primary version of data (the version of data previously recalled) is erased.

In view of the foregoing considerations, there is a manifest need for an improved system which integrates Migration Level Two (ML2) and backup tape processing. The system should avoid tape mounts if possible. The system should include provisions for files backed up after the migration process, such that these files map be restored to the migrated state upon recovery. Such a feature is not offered by existing systems because these systems cannot back up migrated files. It would be desirable to have all tape volumes included within one large tape pool, as opposed to having separate tape volumes for the migration repository and the backup repository. It would also be desirable to integrate the migration inventory and the backup inventory. Furthermore, it would be desirable to develop an improved method for performing an archive of a file that is migrated to ML2 tape. Such a method should minimize the amount of data transfer operations and/or the number of tape mounts which are required.

SUMMARY OF THE INVENTION

The invention provides an improved system for integrating migration level two (ML2) and backup tape processing. The system provides for the backup, archival, and/or restoration of ML2 tape files without the use of tape mounts. In this manner, the amount of data movement required to recover from data loss is significantly reduced. The invention provides a function whereby tape files may be recovered to their original status, even if the file had migrated to ML2. The status of the data is preserved after such a recovery operation. In this manner, data movement is reduced because no remigration of data is required after a recovery.

The invention sets forth a novel method for providing enhanced ML2 and backup tape processing. An inventory entry corresponding to a specified migrated file is updated to indicate that the file is archived in addition to migrated. The use of tape mounts is not required. No data movement is involved. Only one inventory update is required, and primary data need not be erased.

BRIEF DESCRIPTION OF THE DRAWINGS

The various features, aspects, and advantages of the present invention will become apparent from the following more particular description thereof, presented in conjunction with the following drawings.

FIG. 1A is a pictorial representation and partial block diagram of a prior art system including migration and backup functions.

FIG. 1B is a pictorial representation and partial block diagram of the basic operational environment of the present invention.

FIG. 2 is a block diagram illustrating an exemplary prior art data structure, each object having a single inventor entry, used in conjunction with data storage management systems.

FIG. 3 is a block diagram illustrating the data structure for a backup/migration inventory used in conjunction with a preferred embodiment of the present invention.

FIG. 4 is a block diagram illustrating an exemplary data structure for a backup/migration inventory fused in conjunction with a preferred embodiment of the present invention.

FIG. 5 is a flowchart setting forth the operational sequences used to implement a migrate operation according to a preferred embodiment of the present invention.

FIGS. 6A and 6B are a flowchart setting forth a process for making logical copies of files in ML2 during a filepool backup operation according to a preferred embodiment of the present invention.

FIG. 7 is a block diagram illustrating an exemplary data structure for a backup inventory used in conjunction with a preferred embodiment of the present invention.

FIG. 8 is a flowchart setting forth the operational sequences used to implement filepool restore and filepool fileload functions according to a preferred embodiment of the present invention.

FIGS. 9A-9I set forth specific examples of the manner in which the operational sequences of FIGS. 5, 6A, 6B and 8 may be applied to the data structures of FIGS. 3, 4, and 7.

FIGS. 10A and 10B are a flowchart setting forth program flow for a subroutine entitled "backup.sub.-- ML2.sub.-- storage.sub.-- group".

FIGS. 11A-11E are a flowchart setting forth program flow for a subroutine entitled "restore.sub.-- ML2.sub.-- storage.sub.-- group".

FIGS. 12A-12D are a flowchart setting forth program flow for a subroutine entitled "restore ML2 file".

FIG. 13 is a block diagram illustrating an industrial application of the invention.

FIG. 14 is a block diagram illustrating the invention as executable software in a computer system.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

FIG. 1A is a pictorial representation and partial block diagram illustrating the operational environment of a known data storage management system. An example of such a data storage management system 100A is the IBM Data Facility Storage Management Subsystem for Virtual Machines software, hereinafter referred to as DFSMS/VM. (DFSMS is a trademark of the IBM Corporation.) The DFSMS/VM software implements various operational sequences for the purpose of storing and inventorizing data using migration level two (ML2) techniques, as described above in the Background of the Invention.

The data storage management system 100A shown in FIG. 1A (for example, DFSMS/VM) implements various operational sequences for the purpose of storing and inventorizing data. The DFSMS software operates in conjunction with the Virtual Machine (VM) series of operating systems. Although the currently available version of DFSMS/VM software does provide space or availability management, the software provides several improvements to the Virtual Machine (VM) series of operating systems.

A relatively new file system, know as the shared file system, or "SFS", is included in current releases of IBM VM operating systems. (SFS is a trademark of the IBM Corporation). Shared file systems significantly reduce underutilization and fragmentation problems as contrasted with the minidisk file systems (MFS) in common use in various prior art systems. The advantage of SFS is that it allows for the dynamic sharing of peripheral storage space among different users. Physical storage space is not preallocated to a user account as in presently-existing MFS systems. Instead, as each user actually stores a file, storage space is dynamically allocated for that file only. Users are given accounts to a file pool, which may be defined as a collection of files for a set of users.

In VM operating systems, a file pool is comprised of a collection of minidisks owned by a single virtual machine that contains files for a number of users. Each user stores files in a logical file space within a SFS storage group, which is a collection of minidisks within a file pool. The storage space assigned to a file changes dynamically as files are added thereto, deleted therefrom, or updated. The files in each file space may be organized into one or more directories and/or subdirectories, the file space itself representing a top level of the directory hierarchy.

Each data storage management system with data managed by DFSMS/VM has one and only one instance of DFSMS/VM. This instance of DFSMS/VM becomes the DFSMS/VM client. Every client (i.e., every instance of DFSMS/VM) is provided with the capability to manage its own data.

SFS includes control information in level 0 storage as part of every file pool. The control information includes files of information used to locate minidisks in the respective file pool, and to track which blocks of such storage space are in use. The control information also includes a catalog of information about the directories and files in the file pool, such as the owner of each file. Multiple file pools can exist for each instance of DFSMS/VM, each file pool being an instance of SFS.

The data storage management system 100A of FIG. 1A is equipped to perform six major functions. These functions are migration, backup, archive, recall, recovery, and retrieval.

Migration is the movement of data from a first data storage medium to a second data storage medium. The second data storage medium is usually of lower cost and performance that the first medium. The data are migrated in conformance with customer-defined data reference patterns on the media. The migration copy remains the primary (active) version of the data. No explicit action (besides specific reference) is needed to recall a migrated copy of the data.

Backup refers to the copying of data in order to guarantee data availability. A backup copy is an inactive (or second) version of data. The primary (active) copy of data remains unchanged. Explicit action is required to recover a backup copy of data.

Archive is similar to backup, except that the active version of the data is deleted. Explicit action is required to retrieve an archive copy of data.

Recall refers to the restoration of a file that was migrated. Recovery refers to the restoration of a file that was backed up. Retrieval refers to the restoration of a file that was archived.

In FIG. 1A, the data storage management system 100A employs a file system 102A which contains one or more files, such as file 1 (reference 104). The data storage management system includes backup processes 106A and migration processes 108A. The backup and migration processes 106A and 108A use separate inventories. These inventories are the backup inventory 105 and migration inventory 107. In this regard, "inventory" is a data set that describes the contents of an auxiliary storage device. The data set is composed of one or more entries which identify and provide the storage locations of files which are in an auxiliary storage device. An inventory may refer to more than one auxiliary storage device, but, in the prior art, backup inventories refer only to storage devices having backup files, while migration inventories refer only to auxiliary storage devices having migration files. In the prior art, since the backup processes 106A operate independently of the migration processes 108A, the data storage management system 100A creates separate copies of a file (file 1, referred to by reference number 104) on separate auxiliary storage devices such as tape device 1 (reference number 110) and tape device 2 (reference number 112). Not shown, but implicit in FIG. 1A is a requirement to provide a separate inventory and auxiliary storage device for archiving processes.

FIG. 1B illustrates the present invention in several embodiments. All embodiments of the invention include a storage management system 100B, a file system 102B, backup processes 106B, and migration processes 108B. These components correspond with the similarly numbered components in FIG. 1A, with additional functions necessary to practice the invention. All embodiments of the invention also employ a single inventory 200 which serves to describe the contents of auxiliary storage for migration, backup and archiving.

The most efficient embodiment of the invention employs a single physical copy of file 1 (reference number 104) for all auxiliary storage purposes including migration, backup and archiving. For example, if file 1 is already migrated when the backup process 106B runs, the backup process 106B merely adds an inventory entry to the inventory 200 which points to the auxiliary storage location of file 1 for all auxiliary storage purposes denoted in the inventory. Similarly, if file has been backed up before the migration process 108B runs, the migration process merely adds an inventory entry pointing to the auxiliary storage location of file 1, which was stored there by the backup process 106B. This implies that only a single auxiliary storage means needs to be provided for all auxiliary storage purposes.

In the most conservative embodiment of the invention, when Separate copies of data are deemed necessary for the separate auxiliary storage purposes, separate, dedicated auxiliary storage devices such as tape device 1 and tape device 2 (110, 112, respectively) may be provided for those purposes. Of course, if the storage management system 100B is to provide the full complement of auxiliary storage functions and the data storage management control procedure requires storage of the copies on separate physical media, the system configuration would require either a mount/demount procedure to provide separate physical media on a single auxiliary storage device, or a number of separate auxiliary storage devices as there are auxiliary storage purposes in the storage scheme of the system.

FIG. 2 illustrates an example of an inventory data structure which may be used in conjunction with the data storage management system 100B of FIG. 1B to perform data storage management using migration level two (ML2) techniques. The operational sequences used by the system 100B to practice the invention utilize the backup/migration inventory 200. These operational sequences may use functions found in the "workstation data save facility" (WDSF) available by the assignee of this application. (WDSF is a trademark of IBM Corporation, the assignee of this application). As is known, workstation data save facility functions provide for client-interactive data storage management by means of interfaces called "verbs".

One function of verb interfaces is to create data objects 202, 204, 206, 208. Verbs employed for this purpose are referred to as "insert verbs" 210. The insert Verb 210 creates a data object 206 by placing an entry into the inventory 200 and storing the associated data on tape. If it is desired to delete a data object 204, a "delete verb" 212 is used to accomplish this function.

The use of insert verbs 210 and delete verbs 212 to create and destroy data objects. 202, 204, 206, 208 provides a relatively straightforward approach to data storage management. Such an approach is highly useful for systems where the user is only concerned with retaining ML2 data for the purpose of later data recall.

With reference now to FIG. 3, the data management system of the present invention offers an enhanced technique for data retention which is employed in the context of data restoration and/or retrieval. The invention provides migration, archive and/or backup processes with data constructs termed "claims" 303, 305, 307, 309. Each claim 303, 305, 307, 309 is represented by an entry in backup/migration inventory 200 corresponding to associated data objects 311, 313, 315, 317, 319. A given data object 311, 313, 315, 317,319 will only be retained for so long as there are claims (inventory entries) 303, 305, 307, 309 associated with it. When the last claim (inventory entry) 303, 305, 307, 309 associated with a given data object 311, 313, 315, 317, 319 is deleted, the data object 311, 313, 315, 317, 319 will be deleted as well. A migration, backup or archive process, such as, for example, the filepool backup process described below, will create its own claim (inventory entry) 303, 305, 307, 309 to the data objects 311, 313, 315, 317, 319.

Claims (inventory entries) 303, 305, 307, 309 are related to data objects 311, 313, 315, 317, 319 through the use of unique data object identifiers (DOBI's) 327, 329, 331, 333 which point to inventory data objects. Each DOBI 327, 329, 331, 333 must satisfy the requirement of being unique with respect to all other DOBIs 327, 329, 331, 333 corresponding to the client associated with the specified data object 311, 313, 315, 317, 319.

The present invention provides an improved data construct for the DOBI's 327, 329, 331, 333. According to the present invention, DOBI's 327, 329, 331, 333 are structured to include a unique object identifier (OID) 321 of an original file, a filepool name 323 identifying the pool containing the original file, a time stamp 325 indicative of the time of creation of a data object identified by the DOBI, and a pointer 326 to the data object. As previously stated, each system with data managed by DFSMS/VM has only one instance of DFSMS/VM. Accordingly, if a given filepool of a given system is considered, the unique object identifier 321 for a migrated file is guaranteed to be unique at any given moment in time. In a similar manner, the DOBI 327, 329, 331, 333 is also guaranteed to be unique.

An alternate embodiment of the invention employs the data object identifier (DOBI) 327, 329, 331, 333 in a novel manner. In this approach, the data object identifier 327, 329, 331, 333 is created from a unique entry identifier (UEI) 320 assigned to any inventory entry 303, 305, 307, 309, 311, 313, 315, 317, 319 by the backup/migration inventory 200. In the invention, more than one claim (inventory entry) 303, 305, 307, 309 can be created with the same DOBI 327, 329, 331, 333 referencing the same data object 311, 313, 315, 317, 319. When a data object 311, 313, 315, 317, 319 is pointed to by a plurality of claims (inventory entries) 303, 305, 307, 309, these additional claims 303, 305, 307, 309 provide access to the same data for different purposes. The multiple entries design of the present invention offers the capability of supporting several different types of claims 303, 305, 307, 309, including migrate entries, backup entries, and archive entries.

To complete the description of the inventory 200 in FIG. 3, each data object points to an auxiliary data storage location where a file is located. This provides a complete trail from a claim to a stored file. For example, assume in claim 303 that the DOBI 327 in its object identifier field identifies file 1 and points to the data object 313. The data object 313, in turn, points to the auxiliary storage location where file 1 is stored, which may be accessed for recall, recovery, or restoration by way of the auxiliary storage device 110.

The data storage management system includes a function which instructs backup/migration inventory 200 server functions to delete one of a plurality of claims 303, 305, 307, 309 (inventory entries) from the backup/migration inventory 200. When the last remaining claim 303, 305, 307, 309 (inventory entry) corresponding to a particular data objects 311, 313, 315, 317, 319 is deleted, the data object itself is also deleted. Accordingly, a valid data object 311, 313, 315, 317, 319 will always be associated with at least one claim 303, 305, 307, 309 (inventory entry). The backup/migration inventory 200 can be searched for all of the claims (inventory entries) 303, 305, 307, 309 associated with a particular data object 311, 313, 315, 317, 319 because they are all related by the same data object identifier (DOBI) 327, 329, 331, 333.

FIG. 4 illustrates the data structure for a multiple entries embodiment of the present invention as applied to the task of migrating files to ML2. When a file is migrated to ML2, the data storage management system 100B creates two software objects in the backup/migration inventory 200 by means of an insert verb 210 (FIG. 2). The first object is a data object 401 which includes inventory entries 403 and respository file pointers 405, which point to respository files 406. The repository files pointed to by the data object. 401 include the actual file data stored on tape.

The second software object created