Re: BRMS full copy versus Cumulative Copy between two Power systems -- MIDRANGE-L

Laurence -

1. If that is the actual command, the TGTRLS parameter could be updated
to reflect the current releases of your systems (V7R1 instead of V5R4).
You aren't really hurting anything if you don't change it but if you get an
object that requires a higher release of OS support than V5R4, you won't be
able to save it with this particular command due to the V5R4 specification.

2. If you're happy with the process as it is - you can make the suggested
tweaks and proceed as usual

3. Yes, you have the concept - this is a differential save. SAVOBJ and
SAVCHGOBJ are both restored with the RSTOBJ command - it will restore
objects from your SAVF regardless of how they were saved. You can also use
RSTOBJ to restore objects saved with the SAVLIB command should you perform
a SAVLIB and only need to restore 1 or 2 objects rather than the entire
library.

4. see #3 above.

Do you have BRMS on your system? (GO LICPGM option 10 - look for
5770-BR1). If so, is it being used? You referenced BRMS in your initial
email, which brought about a couple of responses regarding its' use in
resolving your issue. If you have BRMS, you may wish to review those
responses.

Thanks,

Steve McKay
(205) 585-8424
samckay1@xxxxxxxxx

On Thu, Apr 23, 2020 at 6:31 PM Laurence Chiu <lchiu7@xxxxxxxxx> wrote:

Hi all

To respond to all the comments which have been really helpful.

1. The command I posted is actual - not something I grabbed from the NET
:-( The command is executed on a Power 6 I think running IBMi 7.1. The
target machine is a Power 8 running 7.1 but will be upgraded to 7.3. A
second Power 9 is going to be purchased. Maybe they have been using this
command for ages and it works so they never bothered to change it. To add
some context there are 3 servers. Prod, DR and third site backup. Prod and
DR are kept in sync using Mimix. The third site was a regulatory
requirement to have a third copy so somebody I guess knocked up a command
to dump the data that could be loaded. Since it was only to have a third
copy of the data accessible for review, and the connection to the third
site was over dark fibre and then GbE, nobody was concerned about
efficiency. Now the third site is going to b 2600km away, this is now a
concern.

2. The requirement for the third site is going to be for the next 6-8
months, not permanent. So we need something that is reliable for that time.

3. Steve you note that I change the SAVOBJ to SAVCHGOBJ, it will save only
objects that have changed since the last full backup. Then the file to be
shipped will be much smaller. So then (again displaying my lack of
knowledge in this area), then there is an equivalent command to restore
which is the RSTOBJ. That will restore the smaller file and effectively
only apply changes? Is that analogous to taking a differential image copy
each day? So over time the differential between the base copy and last
version will grow as updates occur? That would be fine since once a month
we could ship over another full save file when the network was less loaded.
Then the following SAVCHOBJ would be much smaller.

4 We don't have a VTL at the remote site so from what I have been reading,
using SAVCHGOBJ would be the short-term answer. Is the restore command the
same for a full save versus a changed save?

Does that seem a reasonable approach?

Thanks again

On Thu, Apr 23, 2020 at 11:20 PM Rob Berendt <rob@xxxxxxxxx> wrote:

Laurence,

Paul and Steve offered both good but totally different ideas. That
doesn't make one better or worse than the other.

Paul must be set up like me where he is using a VTL which replicates to
the other site, or his two machines are local to his VTL or physical tape
library.

If bandwidth remains an absolute premium, and will remain so for the long
term and not just an interim solution until all your data centers are
upgraded, then you might be better off looking at a full fledged data
replication system. I've heard of them but have no experience with them
nor do I get any kickback from them so take that as an independent

thought.

Now, one part which really concerns me about your image is the following:
TGTRLS(V5R4M0). This alone tells me you are running on very ancient
unsupported hardware and software. This will severely limit solutions to
your problem. Unless that is just something you copied off of some
internet site. But I don't think so since you obfuscated part of it.

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

-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of
Laurence Chiu
Sent: Wednesday, April 22, 2020 4:39 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx

Subject: BRMS full copy versus Cumulative Copy between two Power systems

CAUTION: This email originated from outside of the organization. Do not
click links or open attachments unless you recognize the sender and know
the content is safe.

Sorry if this question seems a bit simple but in my defence I am not a
Power systems expert and my only source of expertise is our outsourcer

and

I want an independent view also to validate what they tell me.

The situation is the environment I am working is has two Power
installations (IBMi of course) and each night a full backup of the

database

is taken and FTP'ed to a second site and restore. The command to create

the

back looks like this

https://bit.ly/2yw6kdz

I have blanked out sensitive information like filenames but I presume the
command still makes sense.

The output files are then sent to the other installation and restored. At
the moment the second Power server is only a few hundred metres away and
connected over GbE. So no problems. But the second server is now being
moved 2600Km away and on a 200Mbs line. That is causing network issues.

It

seems to me that if the command above is a full copy, then a better
solution might be to take a cumulative (differential I am used to saying
from my DBA days) and sending that across. That would be significantly
smaller. My question is, can this cumulative copy be loaded in the target
system when records of the last full copy don't really exist in the

target

BRMS. Unless once the full copy was loaded in the target system, then a
full copy was taken to create that record. But would BRMS be smart enough
to know that the subsequent Cumulative was related to the full copy taken
remotely.

Thanks
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com