Re: [Bulk] Re: Force Restore of files tagged UNIT(*SSD) to Spinny Disk

[DrFranken <midrange@xxxxxxxxxxxx>]

CRTDUPOBJ FILEID(*YES) is your friend here. :-)


        - Larry "DrFranken" Bolhuis

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

On 3/3/2016 12:43 PM, Mark S Waterbury wrote:

> Larry:
>
> Be aware that use of CRTDUPOBJ in the manner you described will likely
> result in the new file residing in the "training" library  having a
> different "File Level ID" from the original file, and that will require
> the use of ALWOBJDIF(*FILELVL) on the RSTOBJ command.
>
> Mark S. Waterbury
>
>  > On 3/3/2016 11:33 AM, DrFranken wrote:
> > Mark,
> >
> >     I'm Liking this option. The issue I think that will be the
> > thorniest is any new tables or tables that are modified (add/change
> > columns etc) will need to be updated on this library as well or the
> > restore will have issues with the target table.
> >
> >     One would guess though that you could write a CL that does DSPFD
> > to an output file at the beginning of the process. Use that to compare
> > the record identifier of the tables. Any that are different simply get
> > deleted from the training library, then CRTDUPOBJ with DATA(*NO) to
> > create the correct target layout and then CHGPF to UNIT(*ANY).
> >
> >     At the top of our list to pursue.
> >
> >         - Larry "DrFranken" Bolhuis
> >
> > www.Frankeni.com
> > www.iDevCloud.com - Personal Development IBM i timeshare service.
> > www.iInTheCloud.com - Commercial IBM i Cloud Hosting.
> >
> > On 3/3/2016 10:15 AM, Mark S Waterbury wrote:
> >
> > > Hi, Larry:
> > >
> > > I ran some quick empirical tests using a file with one member, saving to
> > > and restoring from a save file.
> > >
> > > It appears that your method "d" should work. You need to use RSTOBJ vs.
> > > RSTLIB, and specify OPTION(*OLD), e.g.:
> > >
> > >    RSTOBJ OBJ(*ALL) SAVLIB(lib1) DEV(TAP01) OBJTYPE(*ALL) +
> > >             MBROPT(*MATCH) OPTION(*OLD) RSTLIB(lib2)
> > >
> > > Also, you do not need the "CLRPFM" ahead of time, since the restore will
> > > replace the data space for each member.
> > >
> > > HTH,
> > >
> > > Mark S. Waterbury
> > >
> > >  > On 3/3/2016 9:17 AM, DrFranken wrote:
> > > > Have a customer with SSD and Spinny. Many files in production DB
> > > > tagged UNIT(*SSD).  Monthly they restore production backup (about 1TB)
> > > > to training library and you guessed it all those files pile on the
> > > > SSDs overfilling them. Any idea how to make the Restore override the
> > > > UNIT(*SSD) and put them on spinny disk?
> > > >
> > > > i 7.1 in play. Three cores, 128GB, about 60 total arms.
> > > >
> > > > Thoughts so far:
> > > >
> > > > a) There are no parms on RSTLIB or RSTOBJ to override the Unit, only
> > > > the ASP and Library. The Library is overridden of course in this
> > > > restore.
> > > >
> > > > b) Customer has restored, then changed the PFs to *ANY, then RGZPFM on
> > > > the things and this seems to move them to Spinny but takes days.
> > > >
> > > > c) Customer is entertaining an iASP or user ASP. However this means
> > > > adding more disks and enough of them that the Restore doesn't take
> > > > forever and that training performance isn't pathetic.
> > > >
> > > > d) Would it Work to instead of clearing the library clear the members
> > > > in the training library. Then change those PFs to UNIT(*ANY) and
> > > > restore into them. The question is would RSTLIB in this case restore
> > > > the attributes of the PFs anyway thus changing the UNIT parm back to
> > > > *SSD. We're going to try this with a small sample library but if
> > > > anyone has tried this...
> > > >
> > > > Engage Discussion. :-)