Re: BRMS scatter saves

[Evan Harris <auctionitis@xxxxxxxxx>]

Do you need all the receivers in the one library i.e. do they all need to
be part of the same chain or could you archive them off into other
libraries to spread them around for save purposes ?

On Wed, Sep 21, 2016 at 7:00 AM, Rob Berendt <rob@xxxxxxxxx> wrote:

> Thanks.
>
> Our "big" library is journal receivers.  We do INSANE retention of journal
> receivers.
> When you think of a restore strategy you should have your receiver library
> restored before your data library.  So you shouldn't do
> *ALLUSR (except #BIGLIB)
> #BIGLIB
>
> You could do
> #BIGLIB
> *ALLUSR (except #BIGLIB)
> But do you want it there before QUSRSYS and QGPL?
>
> But one or the other is the only work around if you want to scatter save
> #BIGLIB.
>
> 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:   "Steinmetz, Paul" <PSteinmetz@xxxxxxxxxx>
> To:     "'Midrange Systems Technical Discussion'"
> <midrange-l@xxxxxxxxxxxx>
> Date:   09/20/2016 02:33 PM
> Subject:        RE: BRMS scatter saves
> Sent by:        "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
>
>
>
> Rob,
>
> I remember discussing this in a previous thread.
>
> I have a similar situation with one of my libraries, 5 times larger than
> any other library.
>
> The problem I have with IBM's solution is that you have to hardcode
> libraries and objects within BRMS using multiple control groups.
> I prefer not to do this, because every time a new library is created or a
> library is deleted, you must revisit your BRMS control groups config.
> I'm a strong advocate of *alluser, no changes needed to BRMS when new
> library is created or a library is deleted, and you know you are backing
> up 100%.
> Prior to using *alluser, we were burned in the past when someone created a
> new library, and it wasn't added to the save.
>
> Gave you a vote.
>
> Paul
>
> -----Original Message-----
> From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Rob
> Berendt
> Sent: Tuesday, September 20, 2016 1:34 PM
> To: Midrange Systems Technical Discussion
> Subject: Re: BRMS scatter saves
>
> Sounds familiar, like I've discussed this before.
>
> Anyway, I opened up an RFE and if this pertains to you then I'd appeciate
> your vote.
> https://www.ibm.com/developerworks/rfe/execute?
> use_case=viewRfe&CR_ID=94797
>
>
>
> 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:   Paul Roy <paul.roy@xxxxxxx>
> To:     Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
> Date:   09/20/2016 12:59 PM
> Subject:        Re: BRMS scatter saves
> Sent by:        "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
>
>
>
> It could have changed ... but to my understanding parallel save cannot be
> setup for *ALLUSER
>
> http://www-01.ibm.com/support/docview.wss?uid=nas8N1012281
>
> Paul
>
>
>
> From:   Rob Berendt <rob@xxxxxxxxx>
> To:     midrange-l@xxxxxxxxxxxx
> Date:   20/09/2016 16:22
> Subject:        BRMS scatter saves
> Sent by:        "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
>
>
>
> We spread our saves among four drives in our library.
> Objects within a library are currently not scattered among the drives.  Is
>
>
>
> there a way to get it to do so?
>
> The problem is we have one extremely large library  (looking at breaking
> that down but that will be difficult at best).
> It's still saving for three hours after the other libraries in the *ALLUSR
>
>
>
> part are done.
> I'm sure that if it would scatter we bust that time by potentially 1/4.
>
> *LINK save scatters.
>
> While I am more concerned about the time if I was still using physical
> tape I would also be concerned about this
> Volume          ---Temporary Errors---   --------M Bytes--------
> ID                    Read       Write         Read      Written
> G00129                   0           0            1      1572815
> G00130                   0           0            1       549684
> G00131                   0           0            1       873180
> G00132                   0           0            1       552368
> G00133                   0           0            1       665417
> The big library starts out on G00129.  Fills that up and,
> instead of using the empty space on 130-132,
> it loads up another tape (G00133) and continues the save on from there.
> Got this data from PRTERRLOG.  I ran it with VOLSTAT(*DLT) right before
> the save to clear the old data.  These numbers are pretty close to what
> our VTL tells us was 'written'.
>
>
> 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
>
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
> list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>
> Please contact support@xxxxxxxxxxxx for any subscription related
> questions.
>
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
> list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>
> Please contact support@xxxxxxxxxxxx for any subscription related
> questions.
>
>
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
> list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>
> Please contact support@xxxxxxxxxxxx for any subscription related
> questions.
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
> list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>
> Please contact support@xxxxxxxxxxxx for any subscription related
> questions.
>
>
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>
> Please contact support@xxxxxxxxxxxx for any subscription related
> questions.