Re: replicate PROD iseries box to distant TEST box cross-country

I guess that a TCP/IP version of the SAVRST* family have been duplicated
by a number of people. However, I wonder if any of them have done it
using the save/restore to/from application APIs and their own sockets
application to start the send before the save was complete and to start
the restore before the comm is complete? Thus enhancing performance and
reducing temporary storage used.


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: Evan Harris <auctionitis@xxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>,
Date: 10/14/2013 02:14 PM
Subject: Re: replicate PROD iseries box to distant TEST box
cross-country
Sent by: midrange-l-bounces@xxxxxxxxxxxx



Let me tell you what I observed and why I made this statement.

We had a customer that had a requirement to make a copy of a library but
was somewhat storage restricted. Not hugely so, but enough that when we
copied the library to a save file the storage was getting high enough that
it made them nervous, particularly as they are a HA shop and liked to
leave
headroom for their journal receivers.

We tried CRTDUPOBJ, CPYLIB (which seems to be a bundled version of
CRTDUPOBJ) but all methods of attempting to create a library copy had
problems other than some kind of save and resto5e.

Eventually I set up a remote system to connection to the same box and did
a
SAVRST onto the same machine. What we saw once that was running was:

- Storage never went as high as saving to save file; in fact if I remember
rightly it used around 50% of the storage using a save file used at it's
peak. I suspect this would be different depending on the contents and make
up of the library.
- It completed faster than the save and restore to save file which was
quite a bonus.
- I think (and it'a a few years ago now) that bits of the library were
restored during the restore, kind of like you see when doing a restore
from
tape. I;d need to do it again to put my hand on my heart and swear to
this.


It was clear to me from watching this that:

- It does not wait until the enitre object is saved before it begins
transmission - it actually starts transmission pretty quickly
- The save appears more like a save to tap than a save to sav file
- The connection is visible before the save is completed

I am pretty sure temp storage is involved somewhere but I am certain it is
quicker FTP in at least some if not many cases.



On Tue, Oct 15, 2013 at 12:26 AM, <rob@xxxxxxxxx> wrote:

How does SAVRSTOBJ use less storage? Doesn't it still save it first?

Just

not to anything you can see but instead something in temporary storage?
It's not like it initiates communications before the entire object is
saved, eh? It doesn't start transmission until the entire object is

first

saved into temporary storage, right?


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: Vikhyath Kamath <vikyat_kaamath@xxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>,
Date: 10/11/2013 12:26 AM
Subject: Re: replicate PROD iseries box to distant TEST box
cross-country
Sent by: midrange-l-bounces@xxxxxxxxxxxx



I thought we could do SAVE while active to Save files!!

Also, doesnt the SAVRSTOBJ needs SNA setup?



On Wednesday, October 9, 2013 11:38 PM, Evan Harris
<auctionitis@xxxxxxxxx> wrote:

Hi Joel

Is this just one library, or more than one ?

If more than one do the objects and data need to be in synch in the

saved

libraries ? If they need to be in synch, are you stopping any processes
that might cause updates while the save takes place ? This is where a

save

to virtual tape might prove more effective as you can use save while
qctive
to minimise the outage window and also save all the libraries in hit.
Saving to save files won;t allow you to do that.


If it's only one library and the machine is another IBM i I would skip

the

FTP option and go with SAVRSTOBJ in most cases. It uses less storage and
is
much tidier, in my opinion.



On Thu, Oct 10, 2013 at 5:03 AM, Stone, Joel <Joel.Stone@xxxxxxxxxx>
wrote:

We are separating our PROD & TEST boxes geographically.

There is approx 30 gig of data & objects to copy.

People in my organization are convinced that tape is the only method

given

the data volume. But tape is cumbersome; takes several days to

transport,

tapes go missing, must be logged out, logged-in, etc.

What other strategies should be considered?


Would the following work well (FTP instead of tape transport)?

1) PROD: SAVLIB to *SAVF

2) ARP-ZIP to compress *SAVF

3) FTP from iseries PROD box to distant TEST box

4) RSTLIB to TEST box



Is it possible that 30 gig could be moved in a few hours? Or is that
unrealistic.


Any suggestions such as further details or better ideas?

Thanks!


______________________________________________________________________
This outbound email has been scanned for all viruses by the

MessageLabs

Skyscan service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________
--
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: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--

Regards
Evan Harris

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


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

--

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


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