BRMS migration now supports the migration of database files (both physical and logical files) within the same ASP. With this capability, the system administrator now has increased control to ensure the most frequently accessed files have priority placement on a faster tier of storage. For example, a migration policy can be set up so that once a file has not been viewed for a period of time (for example: a week or a month), it can be automatically migrated to slower storage within the ASP, and after a period of time (perhaps a couple months) of being dormant, it can automatically be archived out to tape. With dynamic retrieval from archive storage, when the file is needed again, it can be automatically brought back in to disk storage. One example of effective use of this feature is migrating several read-intensive files needed by month end processing to SSDs, and then moving them back to HDDs when the process finishes.
There are some restrictions for using *OBJ list containing database files for migration:
Moving database objects using object list can be done only within the same ASP or IASP.
Specific library names are required. Special values and generic names are not supported.
Support is only for specific member names and *ALL. Generic member names are not supported.
Support is only for database file types (*FILE object type with PF or LF attributes).
The output report for the migration of an *OBJ list is different from the report for a library or a *LNK list. This report will first show the *OBJ list name followed by a break-out of the individual objects from the object list as shown in the following example report output (QP1AMGR):
