RE: Question on BRMS *SYSTEM Backup Control Group.... -- MIDRANGE-L

Below may be helpful.
I used this for my migration back in 2012.
Restoring a System without BRMS When the Save Was Done with BRMS
https://www-01.ibm.com/support/docview.wss?uid=nas8N1014245

Paul

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jim Oberholtzer
Sent: Wednesday, October 24, 2018 4:09 PM
To: Midrange Systems Technical Discussion
Subject: Re: Question on BRMS *SYSTEM Backup Control Group....

Aside from the types of save you are restoring, there is no functional
difference between the "21" and a BRMS save.

The only exception is the multiple device issue I pointed out before.

Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects

On Wed, Oct 24, 2018 at 3:02 PM Rob Berendt <rob@xxxxxxxxx> wrote:

<snip>

We were moving from V7R1 (8202-E4D) to V7R3 (9009-41A).

The problem isn't what is or isn't on the tape. That appears to be
complete. What happens is that users expect to restore V7R1 to a new box,
then do either slip installs of V7R3 or other workarounds to get the
system updated. Their steps fail because the restore commands use labels
that are not on the BRMS created *SYSTEM save. I wish I had this better
documented, but in the midst of an ERP upgrade I just threw it on the back
burner and ran a full, manual system save.
</snip>

For a migration like this it's probably best to just work with them and do
the full system save. For a regular unload/reload I would use BRMS.

Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com

From: "Andrew Lopez (SXS US)" <Andrew.Lopez@xxxxxxxxxxxxxxxxxx>
To: "midrange-l@xxxxxxxxxxxx" <midrange-l@xxxxxxxxxxxx>
Date: 10/24/2018 03:52 PM
Subject: Re: Question on BRMS *SYSTEM Backup Control Group....
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>

First thing: Check the DSPLOGBRM *BKU to ensure there were no

problems.

That's run every day, and we filter through the report to show any errors.
There's nothing there in either our weekly full system saves (as
described) or our more granular dailies.

Second thing: Generate this report: STRRCYBRM OPTION(*SYSTEM)
ACTION(*REPORT)
Look at it to ensure that you have all you need to do a full system

save.

I've started just enough of the system to physically print it off. If

you know what you are doing you can override the spool file and use
transformation services to create a pdf and download that instead.

We run that, and email it out for DR purposes, every day. On Sundays, it
shows just the single tape from that morning's save as the sole tape
needed. Every other day it shows Sunday's tape and the latest daily.

I've done several upgrades this way, following the BRMS recovery

report.

Sure, there are those, even those who are familiar with BRMS, who still

prefer to do a regular GO SAVE 21 for upgrades.

My thought is that if I cannot do an upgrade this way then my backups

are worthless. It's one heck of an effective test.

Now, if you're doing a migration from 7.1 on a P5 to 7.3 on a P9 that

get's a little more interesting.

We were moving from V7R1 (8202-E4D) to V7R3 (9009-41A).

The problem isn't what is or isn't on the tape. That appears to be
complete. What happens is that users expect to restore V7R1 to a new box,
then do either slip installs of V7R3 or other workarounds to get the
system updated. Their steps fail because the restore commands use labels
that are not on the BRMS created *SYSTEM save. I wish I had this better
documented, but in the midst of an ERP upgrade I just threw it on the back
burner and ran a full, manual system save.

That recovery report should also tell you if you are missing anything.

By BRMS standards, we aren't missing anything.

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

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD

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

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD