MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » January 2013

Re: QCLSRC with PF38-SRC attribute



fixed

On 24 Jan 2013 10:02, CRPence wrote:
<<SNIP>>

But if making the change, best to use save\restore instead of
copying the data. Restore the members and data of the saved database
source physical file [with the System/38 attribute] into a new
database source PF file previously created with the same name, record
length, and owner using OPTION(*OLD) MBROPT(*NEW) ALWOBJDIF(*FILELVL)
FILEMBR((QCLSRC *ALL) (QDDSSRC *ALL)). Best before the restore to
also have issued a GRTOBJAUT with REFOBJ from the old version of the
file to the newly created file; that can be done after, but
duplicates some effort across all members that would already have
been done during restore processing.


I think MBROPT(*ALL) is required, as Mark had offered; specifying *OLD vs *ALL for the object Option ensures the restore knows that your intent is to restore into an existing object:
http://archive.midrange.com/midrange-l/201301/msg01186.html

That is what I had stated in the Jul-2010 thread "Subject: PF38-SRC to PF-SRC":
http://www.ibm.com/developerworks/forums/thread.jspa?threadID=340669
"... SAVOBJ, RNMOBJ, CRTSRCPF, CHGOBJOWN /* to match owner of renamed_file */, GRTOBJAUT REFOBJ(renamed_file), RSTOBJ OPTION(*OLD) MBR(*ALL) ALWOBJDIF(*FILELVL). Even if using CRTSRCPF, both the CHGOBJOWN and GRTOBJAUT with reference object are best performed just after the create. ..."






Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot 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 here. If you have questions about this, please contact