Archiving
Data archiving is a technique for saving valuable disk space by selecting infrequently used objects, saving them to tape, save file, IBM i Internal Virtual tape (V5R4 and above), or optical (V6R1 and above) and then deleting them from disk. Archiving saves disk space on primary (fast, expensive) disk because it moves the object to secondary (slower, less expensive) storage. The BRMS-Advanced Functions Feature of 57xxBR1 is required to use archiving and dynamic retrieval
NOTES :
- Archiving needs to be run when system is quiesced to ensure no locking of files
- Develop standards or policies that control the objects being archived. These may include:
- Application Structure - Is it suitable for archiving?
- Length of time object has been inactive before archiving
- Retention period
- Number of copies
- Which objects will be “storage freed”
- Maximum time to recover
- Storage media for archived objects, including ASPs for save files
- Length of time object will remain in a save file before copying to tape
- Who will control the archiving?
- When will archiving take place?
Dynamic retrieval
To allow applications to work seamlessly with objects that have been archived, save with storage free can be used. Save with storage free causes the storage for the object to be moved to a less expensive form of storage but leaves object description on the system. Since the object description is left on the system, applications can still access the object. When the object is accessed by an application, the system will automatically attempt to recall the object data using a restore command, this is called dynamic retrieval.
BRMS enables full tape automation to perform data archiving quickly and effortlessly while appearing seamless in its operation. Because BRMS tracks the information about the objects that have been archived, it can also automatically handle dynamic retrieval of archived object data.
Changing the retrieve policy will affect the action that will occur when an archived object is used - WRKPCYBRM TYPE(*RTV):
- *VERIFY
- An inquiry message is sent for each object being retrieved. When encountered, the user may proceed with the retrieval, delay the retrieval or cancel the retrieval.
- *NOTIFY
- The retrieval of the specified object is immediate with a confirmation message being sent to the user.
- *DELAY
- Mark the object specified for retrieval as delayed. These objects can be retrieved later using the Resume Retrieval using BRM(RSMRTVBRM)command.
- *SBMJOB
- The retrieved object is to be submitted to batch.
- *NONE
- Bypass retrieve processing.
The following table lists when dynamic retrieval will occur or not:
Commands that affect dynamic retrieval
| Dynamic Retrieval Object Type | Operation or Command | Calls Dynamic Retrieval | Dynamic Retrieval Is Not Called |
| Database | Any data base open operation | X | |
| DSPOBJD | X | ||
| OPNDBF | X | ||
| OPNQRYF | X | ||
| DSPPFM | X | ||
| DSPFD and DSPFFD | X | ||
| RTVMBRD | X | ||
| CPYF | X | ||
| SNDNETF | X | ||
| CHGOBJ, CHGOBJOWN or CHGOBJA | X | ||
| CHGPFM | X | ||
| RNMOBJ and RNMM | X | ||
| MOVOBJ | X | ||
| CHKOBJ | X | ||
| ADDPFM and RMVM | X | ||
| CHGPF | X | X | |
| DLTF | X | ||
| RCLSTG | X | ||
| DSPLOG | X | ||
| CRTxxxPGM | X | X | |
| Query/400 | X | ||
| SQL | X | ||
| DFU | X | ||
| Options in PDM | X | X | |
| Client Access file transfers | X | ||
| Start or end journalling | X | ||
| Journal changes | X | ||
| Document Library Objects (DLO) | Viewing a DLO | X | |
| Printing a DLO | X | ||
| Copying a DLO | X | ||
| Moving a DLO | X | ||
| Changing details of a DLO | X | ||
| Changing contents of a DLO | X | ||
Integrated file system or hierarchical file system (HFS) | X | ||
Security changes of a DLO | X | ||
Renaming a DLO | X | ||
| Direct existence of a DLO (CHKDLO, DSPDLONAM, RTVDLONAM) | X | ||
| Indirect existence of a DLO (Dir, WRKDOC, DSPFLR) | X | ||
| Search of a DLO object | X | ||
| Save of a DLO object | X | ||
| Restore of a DLO object | X | ||
| Reclaim of a DLO object | X | ||
| Reorganize a DLO object | X | ||
| Deletion of a DLO object | X | ||
| Dump of a DLO object | X | ||
| Stream Files | Checking out the object (CHKOBJ) | X | |
| Accessing the data of the object (a open(), create), MOV, CPY, or CPYFRMSTMF, CPYTOSTMF) | X | ||
| Adding a new name to the object (RNM, ADDLNK, link(), rename(), Qp0lRenameKeep(), Qp0lRemaneUnlink()) | X | ||
| Indirect existence of a stream file (Stream file objects) | X |
NOTES :
- Document library objects (DLO) that have had storage freed and are accessed through integrated file system (IFS) directory '/QDLS' cannot be dynamically retrieved.
- Library objects that have had storage freed and are accessed through integrated file system (IFS) directory '/QSYS.LIB' or '/<IASP Name>/QSYS.LIB' cannot be dynamically retrieved.
- Dynamic retrieval is only supported for the following types of objects:
- Database files, including QHST files (member level)
- Source files (member level)
- Document library objects
- Stream files
- Dynamic retrieval is NOT supported for the following objects, even if they were saved by specifying STG(*FREE):
- Programs (*PGM)
- Service programs (*SRVPGM)
- Modules (*MODULE)
- SQL packages (*SQLPKG)
- Journal receivers (*JRNRCV)
- If an object has been saved with storage freed by any means other than BRMS, a BRMS inventory of the archived objects is not performed.
- Dynamic retrieval through BRMS is not be possible for objects that were not saved using BRMS. For example, objects can be archived by specifying *FREE for the Storage (STG) parameter on the OS/400 Save Object (SAVOBJ) command. In this case, the save media for the object cannot be located and restored by BRMS without manual intervention and an OS/400 message will be sent to the application to indicate the object could not be found.
- At 6.1 and above, archive lists do not support library omits when using generic libraries.
- Dynamic retrieval will no longer work if a library is moved into a different iASP after objects have been archived.
Duplicate Your Archive Tapes
The implication of archiving an object is that it is saved and deleted or storage freed in one operation. Despite the extensive error checking and correction routines of modern device technology, the only way to check data on media is to read the entire media file. With data archiving the ability to check whether the media produced by a save is readable before you delete it is reduced. Also, eventually all other copies of an object that have been saved in the normal backup procedure will expire, leaving only one copy (on media) of the archived object. This will be the most up-to-date copy.
In summary, data loss exposure created by data archiving is two-fold:
- Limited verification of a media before deletion of the object.
- Eventually there will be only one copy of the object on save media.
For these reasons we recommend that you make duplicate copies (not possible with optical) of archived data immediately and then move them to an off-site storage location.
Archiving spooled files
When archiving spool files, there is a limit of 190,000 spooled files that can be archived in a single operation. If more than 190,000 spooled files exist in an outqueue, users will get a CPF0804 message with a 04 Return Code. To prevent the error, you will need to specify a subset of the outqueue using the File, Job, User or User data options in the spool list.
More information on Archiving can be found here: