× 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.



(V7 information)

There are two parts of BRMS Maintenance that need to be run, and I do it every day on my client machines:

Remove Media Information should be set to remove expired media data including media content.
Run Cleanup Operations should also be *YES

I also allow BRMS to change journal receivers, and reorganize the database. These two options can be done less frequently but they should be at least monthly.

It's the remove media information and the clean up that really saves space in the QUSRBRM objects.

In my view, best practice has the BRMS Maintenance procedure run a short time after all the save activity is done for the day. It can run in the middle of the day if desired, no real system impact should detectable, except maybe the first time it's run.

Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


On 9/13/2012 11:14 AM, Terry Nonamaker wrote:
Possibly the expired idea is not the appropriate thought
....but the following should be run from time to time
....we run it once a week
....you would be surprised what a difference it can make
....as we had a situation similar to this when we went to v6r1

StrMntBrm RgzBrmDb(*Yes)

Right now, I can't remember what it was
......but a policy parameter changed defaults on v6r1 and this was part of
it

Although the physical tapes actually expire
....the data containing that info in QUSRBRM does not get cleared out

Try this, I bet it helps

TN




-----Original Message-----
From:midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jim Oberholtzer
Sent: Thursday, September 13, 2012 5:28 AM
To: Midrange Systems Technical Discussion
Subject: Re: BRMS suddenly requires second tape?

Interesting thought Terry but I can't think of any process in BRMS
maintenance that might cause an extra tape mount. If one file on the tape
is still current (not expired) then BRMS will not expire the tape volume
either.

Still, running BRMS maintenance every day is still a best practice.

Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


On 9/13/2012 7:12 AM,rob@xxxxxxxxx wrote:
> BRMS tells you what tapes to mount. It's not going to tell you to
> mount a tape if the tape has unexpired files on it. For example, if I
> use BRMS to back up my daily data and put 14 days retention on it, and
> my quarterly data and put 400 days retention on it, BRMS won't tell
> me to call Iron Mountain and ask for those tapes until those days are
past.
>
> I suppose you could have done something outside of BRMS, like stored a
> file on there with permanent retention.
>
>
> 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 46755http://www.dekko.com From: "Terry
> Nonamaker"<TNonamaker@xxxxxxxxxxxxxxxx> To: "'Midrange Systems
> Technical Discussion'"<midrange-l@xxxxxxxxxxxx>, Date: 09/12/2012
> 05:43 PM Subject: RE: BRMS suddenly requires second tape? Sent by:
> midrange-l-bounces@xxxxxxxxxxxx I have not read all the other
> responses But, are you sure the tapes are being properly expired thru
> BRMS maintenance ......has anything, however subtle, changed in your
> normal process that this might not run? Just a thought Terry Nonamaker
> -----Original Message----- From:midrange-l-bounces@xxxxxxxxxxxx
> [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of John McKee Sent:
> Wednesday, September 12, 2012 2:14 PM To: Midrange Systems Technical
> Discussion Subject: Re: BRMS suddenly requires second tape? I know you
> esponded that it was not likely. I am wondering what using the tape
> less might do to accumulating temporary write errors. Wouldn't the
> tape still wear out, even if it took a lot longer to do so? I was just
> tossing that out from my ancient experience with 9 track tape.
> Watching the drive toss several feet for a temporary write was
> interesting to watch. Running a PRTERRLOG and checking the general
> errors and errors specific to tapes from the past few days still might
> show something, wouldn't it? I have no knowledge of BRMS, so, again,
> this goes back to old experience. John McKee On Wed, Sep 12, 2012 at
> 3:42 PM, Gerald Kern<jp2558@xxxxxxxxx> wrote:
>> > "I'm not a BRMS expert but to me having that QUSRBRM on a separate
>> > tape would be a big advantage if you had to do a full system restore."
>> >
>> > Agreed Larry - but the cost for tapes just for that would be
> prohibitive.
>> >
>> > "Could tape have temporary write errors? I'm wondering if bad
>> > areas are being skipped."
>> >
>> > Not likely John since we use different tapes each day.
>> >
>> > " I print this to a PDF file on a daily basis and store it on 3
>> > servers in multiple countries."
>> >
>> > Whoa Rob - I thought I was cool just by having my reports in pdf's
>> > in gmail and yahoo...;) But three countries = uber cool!
>> >
>> > --
>> > Thanks, Jerry
>> >
>> > Gerald Kern - Information Technology Programming Supervisor IBM
>> > Certified RPG IV Developer Lotus Notes/Domino Administrator The
>> > Toledo Clinic, Inc.
>> > 4235 Secor Road
>> > Toledo, OH 43623
>> > Phone 419-479-5535
>> > --
--

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.