MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » August 2014

RE: [Bulk] RE: [Bulk] Save/recovery of IFS objects - lock issues



fixed

Mark,

I reviewed the knowledge base docs related to ALWCKPWRT and SAVBRM.
It appears that this is only available with SAVBRM, which is not part of a normal BRMS control group save.
So at this point I'm not sure how to integrate/combine SAVBRM with STRBKUBRM.

Has anyone ever used ALWCKPWRT and/or SAVBRM with STRBKUPBRM

Paul


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Mark S Waterbury
Sent: Saturday, August 09, 2014 11:42 PM
To: Midrange Systems Technical Discussion
Subject: Re: [Bulk] RE: [Bulk] Save/recovery of IFS objects - lock issues

Paul:

See:
http://www-01.ibm.com/support/knowledgecenter/ssw_ibm_i_61/cl/savbrm.htm

Mark

On 8/9/2014 8:01 PM, Steinmetz, Paul wrote:
Mark,

I use BRMS, not seeing ALWCKPWRT as an option with BRMS, only native SAV command.

Paul

-----Original Message-----
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

Paul:

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.

HTH,

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

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

--
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,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.


--
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,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.






Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot 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 here. If you have questions about this, please contact