× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.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 on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.