RE: P7 to P9 test migration/recovery using BRMS - issues/resolutions

Rob,

Item # 3
< Perhaps what it really needed was some save in between the two
Every nights save is a full SWA, the only way of saving the missed objects would be a dedicated save or a system save.

<setting/Changing BRMS Recovery Policy - WRKPCYBRM *RCY - changes not always being saved.
Found an issue.

WRKPCYBRM *RCY has 3 screens.
If you make changes on screen 1 and 2, and scroll to screen 3, but do not make any changes on screen 3, none of changes made on screen 1 and 2 are saved.
IBM support recreated this issue, PTF should be coming.

New BRMS recovery issue.
The order of the sequences presented on a STRRCYBRM *SYTSTEM does not match the order that the items were saved.
Thus, several additional volume rewinds and seeking needed during the recovery, slowing down the BRMS recovery.

Paul



-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Rob Berendt
Sent: Monday, December 31, 2018 10:44 AM
To: Midrange Systems Technical Discussion
Subject: RE: P7 to P9 test migration/recovery using BRMS - issues/resolutions

Item #3: skipped objects from nightly save not being restored from
previous dedicated save.
I would check WRKOBJBRM for the object in question. Perhaps what it
really needed was some save in between the two. For example ERPLXF/IIM
was saved on Saturday's full system save to V00147 and Monday's daily
V01045 but was skipped on Tuesday's V00002.
BRMS should skip trying to restore ERPLXF/IIM from V00147 and ask for
V01045 instead, UNLESS you tell it to use a date range or some such thing.
Somewhere in the logs should be some message, if so.

ps: Saving object detail makes options like WRKOBJBRM more effective.
This is why we do it. However we do not have onerous retention policies.
Saying "this is our policy" makes me wonder who set that policy and why.
And if they have that same policy on PC backups, etc.

Rob Berendt