I use BRMS, not seeing ALWCKPWRT as an option with BRMS, only native SAV command.
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Mark S Waterbury
Sent: Saturday, August 09, 2014 3:04 PM
To: Midrange Systems Technical Discussion
Subject: Re: [Bulk] Save/recovery of IFS objects - lock issues
See the CHGATR command, the *ALWCKPWRT attribute -- you can set this attribute to *YES for individual stream files, or all files in a directory, etc. -- then on the SAV command, you can specify:
SAV ... SAVACT(*YES) SAVACTOPT(*ALWCKPWRT)
I think this attribute will address your concerns #1 and #2 ...
Use google -- search for "*ALWCKPWRT" -- to see relevant discussion of this feature.
Mark S. Waterbury
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
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
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
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.
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.
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.
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l