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

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. :-)