Re: BRMS-Can it speed up our save? -- MIDRANGE-L

Hi rob,

I have recently been through at least part of what you are about to embark
on two 720's

>We are combining two 400's.  Let's call one GDIHQ and one GDIMAIL.  GDIHQ
>runs erp, benefits, etc.  GDIMAIL runs Adstar or TSM, and Domino.  In case
>you didn't know, TSM resides in library space and Domino resides in IFS
>space.

My TSM pools have been created in the IFS. This may be a version thing. We
are on the 3.1.8 or something - the latest for AS/400 anyway.

>I know you can do the trick when you do a save and put in two alike tape
>drives and when one runs out of tapes it jumps to the other.  But that
>really doesn't save simultaneously.
>
>What I am hoping for is a way to use both 3590's simultaneously, in
>restricted state, to do our saves.  Is there a way to do this?  We are
>running V5R1.  We have BRMS but haven't gotten around to using it.

My understanding is that depending on cards and controllers etc you can do
two saves simultaneously although I have not done this yet - maybe later.
Seemed to me like a good idea to get
the save right before playing with them for improvement :)

>If BRMS is the magic pill then how do we go about implementing that?  RTFM
>is acceptable, if you believe that, and point to good links.  I've heard
>that BRMS, under V5R1, is a cinch to get working.  Much different than
>previous releases.

To use TSM on the AS/400 you have to use BRMS - it is effectively the TSM
client. Unless you are backing up data from systems other than the AS/400
(which we are) I would ditch TSM as it just gets in the way in my view.
Consider the following:

- TSM can only save IFS files to disk if you have sufficient disk pools to
store the IFS data being saved prior to export to tape. If you have 20 gb
of IFS data you need a 20 gb storage pool OR you need to start breaking
your save up into discrete chunks less than 20 gb. Having to do this for
reasons other than to maintain a logical save set is a kludge in my view.

- User data also excludes (or appears to) MQ Series journals. Unless you
perform some tricks to save them (like saving them to a sav file in a user
library or something) it won't allow you to save them using TSM.

- QUSRSYS and QGPL also end up in the BRMS tape sets rather than TSM tape
sets - all these extra saves on top of the SAVSYS make management of tapes
rather important.

- As a reult of the above you'll end up with two tape inventories - BRMS
tapes and TSM tapes. This can be a bit of a pain. Tape management
especially at first will probably cause you soem grief - manage it very
carefully :)

- TSM seems to be exceptionally slow compared to native saves to tape. I
had a complete system save of around 10 hours (200 or so gig) balloon out
to something like 18 hours. Not much of an improvement in my book.

- You can't currently use an LTO directly attached to an AS/400 for TSM
saves, although BRMS will happily use the device.

BRMS as noted has quite a learning curve, but with a little help to get you
started, some redbooks and a test box it's not too bad.

I have never quite understood the use of the Domino saves in BRMS as it
appears they do not save everything anyway. I understand that they do not
include databases and other components so your save strategy needs to take
account of this otherwise you may end up with a hole when you restore. The
obvious anwer to me seems to be to replicate the Domino server to a backup
server and shut it down during backups if leaving the production server up
at all time sis of paramount importance.

Hope this is useful

Regards
Evan HArris