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

[DrFranken <midrange@xxxxxxxxxxxx>]

Yep the ASP we see as an option as I mentioned. It's just going to 
require more disks and some management there.

        - 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:13 AM, Steinmetz, Paul wrote:

> I have a similar issue, but the restore is done on a different LPAR.
> BRMS allows you to force the ASP on the RSTLIBBRM
> Auxiliary storage pool . . . . . > &UPRSTASP
>
> Specifies whether libraries and objects are restored to the auxiliary
> storage pool from which they were saved or to a different auxiliary
> storage pool.  Libraries and their contained objects can only be
> restored to the system (1) auxiliary storage pool, a basic user (2-32)
> auxiliary storage pool, a primary auxiliary storage pool or a secondary
> auxiliary storage pool.
>
> I created a 2nd ASP, keeping SSD and spinny separate.
> I have the ability on the RSTLIBBRM if I want the library on SSD or on spinny.
>
> Paul
>
> -----Original Message-----
> From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Rob Berendt
> Sent: Thursday, March 03, 2016 10:07 AM
> To: Midrange Systems Technical Discussion
> Subject: Re: Force Restore of files tagged UNIT(*SSD) to Spinny Disk
>
> Good ideas Darren.
> However,
> 1 - If not all files were changed then you have to keep track of whom to change back to SSD.  Not impossible, just more work.
> 2 - In a DR situation you have to change the attribute after the restore because they would have been saved with the wrong attribute.
>
>
> Rob Berendt
> --
> IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail to:  2505 Dekko Drive
>            Garrett, IN 46738
> Ship to:  Dock 108
>            6928N 400E
>            Kendallville, IN 46755
> http://www.dekko.com
>
>
>
>
>
> From:   Darren Strong <darren@xxxxxxxxx>
> To:     Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
> Date:   03/03/2016 09:54 AM
> Subject:        Re: Force Restore of files tagged UNIT(*SSD) to Spinny
> Disk
> Sent by:        "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
>
>
>
> One more thought.  We used to have a mix of SSD and spinnys. We no longer
> have that, so I cannot experiment.  However, I recall there was a time
> when
> I could alter the UNIT attribute and the move would be made immediately.
> There were other times (either through OS upgrades or PTFs) when I would
> change the attribute and it required a save/restore to make the effect
> felt
> (never tried your RGZPFM).
>
> Anway, I see two possible solutions based on what you find to be the
> behavior.  If the UNIT attribute happens immediately, you do the restore
> and then change the attribute.  If it is delayed, then you change the
> attribute on the source machine, save, and then change the attribute back,
> theoretically not affecting the SSD status on the source machine, since
> the
> affect is not immediate.
>
> > 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?