Migrating documents

IBM® Content Manager OnDemand provides automatic migration to copy documents from disk storage to archive storage (for documents that were not copied to archive storage during the load process) and to make documents eligible for deletion to maintain free space on disk. Automatic migration is provided by using the Start Disk Storage Management (STRDSMOND) and Start Archived Storage Management (STRASMOND) commands. Migration helps to ensure that there is sufficient free space on disk, where faster response time can provide the most benefit to your users.

Important:
  • You should run migration processing on a regular schedule to make sure that a backup copy of your documents gets created as soon as practically possible. If you defer the migration of documents to archive storage, and disk storage were to become corrupted, then you could be left without a copy of your documents.
  • The STRASMOND command must only be run in batch (SBMJOB parameter set to *YES). Running this command interactively (with SBMJOB(*NO)) may cause SQL errors.
  • By default, the QUSROND default instance is used, and will produce the desired results for most systems. You can use an instance other than QUSROND as your default by defining the QDFTINST data area as described in Using Content Manager OnDemand data areas. You can also specify the instance name directly when you run the commands. If you need to run the STRASMOND command for multiple instances, you must issue the command separately for each instance. Note that if you initiate the archive storage manager by running the STRDSMOND command with RUNASM(*YES), then the instance name is passed from the disk storage manager and no further specifications are needed.
  • If you run STRDSMOND for a specific application group (rather than the default of *ALL) and you set the Run ASM (RUNASM) parameter to *YES, be aware that ASM will run for ALL application groups, even though you have named a specific application group for DSM to use. You can, however, name a specific Policy for ASM to process, if desired. Also note that when you specify RUNASM(*YES), Content Manager OnDemand will initiate a separate batch job for ASM.
  • If you specify Cache Data for 90 Days on the Storage Management tab within the application group, DSM will keep the data in the IBM i IFS directory for 90 days after the report date (a segment field) before it removes the data from the IFS CACHE directory. Regardless of the settings on the Storage Management tab of the application group definition, DSM will not delete data before it is sent to ASM. To determine when data is sent to ASM, select the Advanced button on the Storage Management tab within the application group. Data is passed to ASM based on the criteria specified in the Migrate Data from Cache section on the Advanced panel as shown in the table:
    Table 1. Criteria specified in the Migrate Data from Cache section on the Advanced panel of the Storage Management tab
    Criteria Description
    No Data is never passed to the archive media. This option is only allowed if you specify a cache only Storage Set and is not recommended.
    When Data is Loaded Archive objects are passed to ASM when the store process runs from one of the load processes, such as ADDRPTOND, STRMONOND, arsload, arsdoc add.
    Next Cache Migration Archived objects are passed to ASM the next time STRDSMOND is run.
    After xx Days in Cache After reaching xx days, archived objects are passed to ASM the next time that STRDSMOND is run.

    For a basic approach to the expiration of data, the Life of Data and Indexes should be the total of Cache Data days from the application group and the sum of the Duration at this level for all levels of the migration policy that is used for this application group. For example: The value for Cache Data days is 90 days, the migration policy for this application group has two levels, 100 days at the disk pool level and 7 years at the optical level so the Life of Data and Indexes value should be set to 2745 days.

    You can, instead, take a more advanced approach to managing the expiration of your data. If you want to continue to use DSM to manage the expiration of your data, by using Life of Data and Indexes to control expiration, you should consider setting the duration of the last level of the migration policy to Never Expire. This allows controlled movement to a new level if one should be added in the future. If you want to manage the expiration of your data using ASM, using an expire level as the last level of the migration policy, you should consider setting the Life of Data and Indexes to Never Expire. This ensures that DSM will never expire the data. See Eliminating the need to run Disk Storage Manager (DSM) for more information regarding Archived Storage Manager-based expiration.

After the data is sent to ASM and has entered a level as specified in the migration policy, the number of days at that level can only be changed using the Change Policy Level Date (CHGPLDOND) command for that particular data. If you change any of these values in the migration policy (instead of using the CHGPLDOND command), only newly archived documents are affected. All previously archived documents are unaffected.

You control automatic migration processing by scheduling the STRDSMOND and STRASMOND commands to run with the appropriate options. See your operating system information for details about how to schedule tasks. You can also start migration processing by running the command manually.

The STRDSMOND command uses an application group's storage management information to control when movement of data for an application group occurs:
  • If you use Next Cache Migration to control when migration for an application group occurs, then the disk storage manager migrates data from cache each time that you start the STRDSMOND command with the appropriate options.
  • If you use After xx Days in Cache to control when migration for an application group occurs, then a document must be stored in cache for at least the specified number of days before it is eligible to be migrated.

The disk space that migrated documents occupy can be reused after expiration processing completes. When you run migration processing, you should also run expiration processing so that the disk storage manager can reclaim the disk storage space occupied by migrated documents.