|
On 8/9/2014 12:10 PM, Steinmetz, Paul wrote:
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
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
