× 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.



Evan is correct, BRMS would have to be upgraded once it is restore to the
system.

IBM would support a slip installation of the LIC, OS, and BRMS but I agree
this is NOT the way to do it.

The BP is trying to do something that would not be recommended in any case.


The other issue is QGPL and QUSRSYS both critical for the process. I did
not know at first there was a OS upgrade being done at the same time, bad
practice but sometimes needed.

I would load LIC, OS and LPPs (all of them) then to the OS upgrade. Remove
BRMS and restore from tape, then slip install BRMS, which will upgrade it,
then perform the recovery.

I've done that several times, but it becomes time consuming and error prone
if not done carefully.


--
Jim Oberholtzer
Agile Technology Architects

-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxx> On Behalf Of Musselman,
Paul
Sent: Thursday, October 25, 2018 2:06 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: RE: Question on BRMS *SYSTEM Backup Control Group....

There are ways to capture the data for an Option/21 save that don't require
running an Option/21!

See
https://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_73/rzaiu/rzaiurzaiu
267.htm for a list of the steps in a genuine Opt/21.

As long as your backup includes the same things in the same order on a tape,
it'll work the same as if you'd used the GO/SAVE/21.

Paul E Musselman
PaulMmn@xxxxxxxxxxxxx

-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxx> On Behalf Of Steinmetz,
Paul
Sent: Thursday, October 25, 2018 3:00 PM
To: 'Midrange Systems Technical Discussion' <midrange-l@xxxxxxxxxxxx>
Subject: RE: Question on BRMS *SYSTEM Backup Control Group....

< I think of a migration is a completely different operation to a recovery.

+1 totally correct.

And what the BP was attempting was probably not supported by IBM.

Paul

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Evan
Harris
Sent: Thursday, October 25, 2018 2:53 PM
To: Midrange Systems Technical Discussion
Subject: Re: Question on BRMS *SYSTEM Backup Control Group....

Sounds to me like they did a mixed release migration in which case trying to
use a BRMS save would have been a bit off the beaten path. It seems to me
that using BRMS in this scenario would be at least a bit problematic as the
BRMS product itself would be upgraded as part of the migration; the BRMS
products would likely show as *BACKLEVEL until the OS Upgrade steps were
performed.

I can understand a preference for a 21 save during a migration as that would
be my preference also. I think of a migration is a completely different
operation to a recovery.


On Fri, Oct 26, 2018 at 5:25 AM Andrew Lopez (SXS US) <
Andrew.Lopez@xxxxxxxxxxxxxxxxxx> wrote:

Sounds like they were following this:

https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_73/rzamc/rzamc1.
htm

Took me a while to read through that, but it does look like the
process that was used.

Based on the responses, it would seem like I'm wasting my time trying
to make BRMS work like a manual 21 save. If they're willing to use
BRMS, a *SYSTEM is fine. If we're in an upgrade and they want to
follow a special process, it's back to a manual save.

I'm thankful I only face that once every 5 years. Of course, the IBM
directions say to have two backups (something I agree with
wholeheartedly, and did as well), which means doing two manual system
saves, back to back.
Like I said, I'm glad it only happens occasionally.


--

As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.