I need to readdress my IFS save strategy.
As apps move forward, IFS is being used more often, which creates both app and save/recovery issues.
There are several main factors to look at.
1) App has the object first, IFS save will miss the object.
2) IFS save locks the object, app tries access the object and fails.
3) Some IFS folders/objects are only used as temp work area, can be skipped, not needed for recovery.
4) Looking for a method and/or tool that will identify any IFS object in use, and its lock level, the best documentation I've found, even though it is dated,
SC41-5304-03 (V4R4 Backup and Recovery).pdf
This manual give the technical details on save and locking info. Table 23. Lock Type Needed for Save Operation
Solution 1
SWA (Save While Active) is not really an option for the IFS, save immediately skips these objects if in use.
This is because there is no wait time on the SAV command. See doc N1012637 How Save-While-Active on IFS (SAV) Works
https://www-304.ibm.com/support/entdocview.wss?uid=nas8N1012637
Solution 2
Another possibility is to omit the IFS object with an omit entry. See doc N1019103 Omitting Individual Integrated File System Files from a BRMS *LINK Entry
http://www-01.ibm.com/support/docview.wss?uid=nas8N1019103
The problem here is that BRMS recovery will skip these entries, saved during a dedicated system save, omitted on a daily basis.. I experienced this during last migration.
Resulting CPS discussion.
BRMS doesn't keep track of omitted directories. So when directories are omitted using QLNKOMT and BRMS does a *LINK full, BRMS will conclude that it has a full backup of the IFS. Indirectly, the user does have a list of the missing/omitted directories because they can just look in the QLNKOMT list. To restore the data, the customer would need to do a WRKMEDIBRM option 7 next to the *LINK entry from last dedicated save, and restore the omitted directories.
So this is one of those extra steps you can add to the recovery report since BRMS does not keep track of omitted directories, not a code defect.
Solution 3
Change the ATR(*ALWSAV) VALUE from (*YES) to (*NO)
I've experimented with this, however, these items should be saved on a dedicated system save.
Options would be to change all the values to *YES before the SYSTEM save and change them back to *NO after the save.
Or change all the values to *NO before the Daily save and change them back to *YES after the save.
This would be a better solution to simply the BRMS recovery.
Solution 4
This is my latest idea, for IFS locked data.
Change the ATR(*ALWSAV) VALUE from (*YES) to (*NO) for any IFS folder/object that may be in use during a save not needed for recovery.
For items needed for recovery, before start of Daily save, using CPY, make copy of the item, copied item will not have locks, thus can be saved for recovery purposes.
Add these items to customized BRMS recovery report.
I'd like input from others that may be experiencing similar issues, interested in how others are dealing with IFS save/recovery and lock issues.
Thanks
Paul
Thank You
_____
Paul Steinmetz
IBM i Systems Administrator
Pencor Services, Inc.
462 Delaware Ave
Palmerton Pa 18071
610-826-9117 work
610-826-9188 fax
610-349-0913 cell
610-377-6012 home
psteinmetz@xxxxxxxxxx<mailto:psteinmetz@xxxxxxxxxx>
http://www.pencor.com/
midrange.com
