Re: Quickest way to copy data from production LPAR to DEV LPAR

On 29-Sep-2015 06:51 -0600, Steinmetz, Paul wrote:

On Tuesday, September 29, 2015 12:17 AM midrange wrote:

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>

<<SNIP>>

If V7R1 no longer uses savf, why does the object description state
it was restored from QTEMP/OBCSAVF.
<<SNIP>>

Save/Restore information:
Save date/time . . . . . . . . . . . :
Restore date/time . . . . . . . . . : 09/29/15 02:50:03
Save command . . . . . . . . . . . . :
Device type . . . . . . . . . . . . : Save file
Save file . . . . . . . . . . . . . : QTEMP/OBCSAVF

Not on v7r1, nor prior releases; that Device file [attribute SAVF] *FILE object exists for implementation purposes, presumably because the Save\Restore (SR) and the LIC Load\Dump features both implement and use the *object-based OS*, and the QANE... APIs utilize the SR which depends on the LD feature to effect the underlying work that is requested:

[http://www.ibm.com/support/docview.wss?uid=nas8N1015930]
Reference #: N1015930 Historical Number 350465179
"...
Object OBCSAVF is a virtual save file that is not really used for anything other than for performing an ObjectConnect function in processing any SAVRSTXXX command. OBCSAVF is temporarily created during every SAVRSTXXX operation and placed in library QTEMP. ...
..."