× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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



As an Amazon Associate we earn from qualifying purchases.

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

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.