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

I completed my first 4 drive, 4 volume, parallel test BRMS recovery, submitted to batch.
Recovery went from 5 hours to 2 1/2.
However, not without issues.

Waiting for a call back from BRMS SME.


STRRCYBRM, using 4 drives, 4 volumes, submitted to batch.
All jobs completed with no known issues.

*LNKLIST was only remaining item.
Attempting the restore consistently returned

Range of subscript value or character string error.
Message ID . . . . . . : MCH0603 Severity . . . . . . . : 40

Further research, with help of IBM support, revealed that I had deferred LF because of NNN PF not restored.

I re-restored the library with the missing, PF, all the deferred LF were restored, and the MCH0603 also cleared.

In the joblog, preceding the PF not restored, I found this.

CPF0C4C followed by CPF9999
Message . . . . : Cannot allocate object QSZPAVL in library QUSRSYS.
Cause . . . . . : Object QSZPAVL type *PRDAVL in library QUSRSYS is already
locked by another process. If the object is QSZPDOUP type *PGM in library
QSYS, then the object QSZPAVL type *PRDAVL or QSZPAVLI type *PRDAVLI is
being recovered by another process. Otherwise use the Work with Object Lock
(WRKOBJLCK) command to determine which process has the lock. Recovery . . .
: Try the request again when the object becomes available.
01/08/19 14:12:38.416148 QMHUNMSG *N QDBRSPRE QS
Message . . . . : Function check. CPF0C4C unmonitored by QDFCNVPP at
statement *N, instruction X'001B'.
Cause . . . . . : An escape exception message was sent to a program which
did not monitor for that message. The full name of the program to which the
unmonitored message was sent is QDFCNVPP . At the time the message was sent
the program was stopped at higher level language statement number(s) *N. If
more than one statement number is shown, the program was a bound program.
Optimization does not allow a single statement number to be determined. If
*N is shown as a value, it means the actual value was not available.
Recovery . . . : See the low level messages previously listed to locate
the cause of the function check. Correct any errors, and then try the
request again.
01/08/19 14:12:38.416307 QSRRSOBJ QSYS 138C QSRRSLIB QS
Message . . . . : FILE WOMHIPF not restored to CABLEFILES.
Cause . . . . . : See previously listed messages to determine the error.

Paul

-----Original Message-----
From: Steinmetz, Paul
Sent: Monday, December 31, 2018 2:00 PM
To: 'Midrange Systems Technical Discussion'
Subject: 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