I'm pretty sure SAVRSTxxx uses save files. the neat thing is that the save file is transferred to the target system as it gets created so you so not have the extra storage on the source system.

I ran a SAVRSTOBJ and on the target system and the object description detail:

Save/Restore information:
Save date/time . . . . . . . . . . . : 09/29/15 08:46:10
Restore date/time . . . . . . . . . : 09/29/15 08:47:31
Save command . . . . . . . . . . . . : SAVOBJ
Device type . . . . . . . . . . . . : Save file
Save file . . . . . . . . . . . . . : QTEMP/OBCSAVF


--
Bryan


midrange wrote on 9/29/2015 12:17 AM:
Paul,

I think you may have memories of an older version. SAVRSTxxx does not use
save files or large working space.
<from V7R1 Info Center>
When you use an ObjectConnect command, the system moves the object directly
to the target system without using save files or distribution queues.
ObjectConnect provides better performance than other methods for moving
objects between systems, and ObjectConnect does not require additional disk
space to store an intermediate copy of the object that is being moved.
<//end>

Object Connect is free (but if not already installed, add it.
You have 3 options to connect:
.Local area network (LAN) or remote communications line with Advanced
Program-to-Program Communication (APPC) and Advanced Peer-to-Peer Networking
(APPN*).
.LAN or remote communications line with Transmission Control
Protocol/Internet Protocol (TCP/IP) with AnyNet* or Enterprise Extender
support.
.Fiber optic bus with OptiConnect.

We use the IP definitions and is fast. We are slightly smaller, maybe .3 Tb
in a developer refresh, Saved & restored within 2 hours (Power 7+ single
processor). The Save is while active.
We do save access paths so no rebuild. We do restore over the existing lib
so 99.99% objects - only data is changing (we do argue over whether this is
a good idea or not..).
It does start moving & restoring data before finished saving.
http://www-01.ibm.com/support/knowledgecenter/ssw_ibm_i_71/rzarm/rzarmobjcr.
htm
We do stop other processing in receiving partition.

Jim Franz


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Steinmetz, Paul
Sent: Monday, September 28, 2015 12:56 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Quickest way to copy data from production LPAR to DEV LPAR

Ditto SAVRSTOBJ and/or SAVRSTLIB for small amount of data.

However, large amounts of data. .5 tb could take long and use a large
amount of temp space for the temporary savf.

Another solution, which we use often, is to do a RSTLIB or RSTLIBBRM from
your latest production save.
We do a full save on Production every night, following the save RSTLIBBRM on
DEV is run to refresh DEV.
We've automated the entire process, save is 2 hours, restore is 2 hours, P7
LTO5 fiber drives.

Paul

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
DrFranken
Sent: Monday, September 28, 2015 12:34 PM
To: Midrange Systems Technical Discussion
Subject: Re: Quickest way to copy data from production LPAR to DEV LPAR

SAVRSTOBJ Hands down the best way for such things. Can be on line, can
be batch, scheduled etc. Maintains all attributes about the object.

- Larry "DrFranken" Bolhuis

www.Frankeni.com
www.iDevCloud.com - Personal Development IBM i timeshare service.
www.iInTheCloud.com - Commercial IBM i Cloud Hosting.



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-2019 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].