ADSM-L

Re: AS/400 -Reply

1997-06-15 22:57:23
Subject: Re: AS/400 -Reply
From: Dennis Schaffer <Dennis.Schaffer AT MUTUALOFOMAHA DOT COM>
Date: Sun, 15 Jun 1997 20:57:23 -0600
John,

Most of the issues you mention are not AS/400-related so I can probably
take a stab at them to give you some quick information and anyone else can
step in with more specific information; I'm also writing this from home and
don't have the manuals available so some of my answers may seem somewhat
vague

RE:  "The parms I am having trouble with are numerous.   Part of my problem
is knowing in which order I set up pieces of ADSM.  I started with
Initialise Server."

Setting up the server is where you want to start because the clients need a
server to communicate with.  However, you will need to consider some client
issues when setting up the server.  These issues will include what kind
(operating system), how many kinds of clients will you have, how much dasd
are you backing up?  How many copies of each file will you retain and for
how long?  Will you treat different clients differently in that regard?
How much time will be available in the backup window and how much competing
LAN/WAN traffic will there be?  These and many other issues will affect how
you set up the server.

RE:  "Recovery Log and Database Volume-How do I calc how big they should
be?"

The ADSM database essentially records information (filename, client node,
client drive, ADSM volume location, etc.; it doesn't store the actual file
data) about every file that is backed up/archived by ADSM.  If you back up
lots of files and keep them around for a long time, it can get rather
large.  Your storage mangagment policies will be the most significant
factor in sizing the database.  The "Administrators Guide" (I believe)
provides some estimating guidelines for database size, assuming (a big
assumption) you know how much data you will back up.  If you don't know,
you take a stab at it and be prepared to add dasd if you guess low.

The Recovery Log, I believe, is used to store database info between
database backups.  Just like a standard database, you backup the ADSM
database periodically and that backup and the recovery log (and perhaps
mirroring) allows you to restore the database in case it gets corrupted.
Its size will depend on the amount of activity and, probably most
importantly, how often you back it up.  I don't remember if sizing
guideline are available but our recovery logs are 5-10% the total database
size.

RE:  "Under Change Server Options License Terms - What are Space
Management, Device support module, and secondary server And Do I
Care?  Server processing parms-Expiration looks important but I am not
sure what to set to.  If set to 24 when does the clock start?  Database
and recovery log parms, are defaults going to work"

Space Management, I believe (I don't have it), is an optional ADSM feature
that provides a "virtual dasd" function by moving unused files from actual
client dasd to ADSM-managed storage pools (dasd/tape/whatever); the files
are automatically retrieved by ADSM when referenced by the client; if you
are familiar with HSM in the MVS environment, I believe it is very similar.
Also, I don't believe it is supported for all ADSM client/server platforms
and I don't have the specifics on that.

The Device Support modules provide support for different types of tape
devices and these, I believe, are a combination of standard and optional
features.  In our case (8MM Exabyte tape library), I believe the required
modules came with our product.  I don't know what tape devices you are
using and, even if I did, I don't know which device support module features
would be required for those drives; someone else (or your IBM Marketing
folks) will have to help you out here.

I don't know what secondary server is.

Inventory expiration is the process of updating the database to reflect the
logical deletion of obsolete files.  This will be very important unless you
make the mistake of backing up everything forever.  Expiration uses the
storage management policies you establish at implementation (or change
later) to determine whether a given backed-up file is obsolete.  Later, the
reclamation process physically reclaims the space those obsolete files
occupied by moving non-obsolete data to another tape volume.  Its important
to know that once a tape volume is filled or incurs an I/O error, it cannot
be used for new backup data until it is emptied.

RE:  "What problems do I need to watch out for on the 3570?  Also any
suggestions about automation would be helpfull.  I took a 7x24 shop here
and turned it into a lights out (other than tape changes) and don't want to
go backwards."

I can't help you with the 3570; perhaps someone else can jump in.

We use OS/2 servers and automate via having an admin client automatically
issue the "Q ACTLOG" command periodically to look for certain ADSM messages
and page us when it finds one.  We could do more but haven't.  I know a lot
of people using the AIX ADSM server forward messages to Netview/AIX as
traps and some of them do a lot of sophisticated things.  I don't know how
automation would work in the AS/400 environment.  It would probably be
dependent on having an interface between your AS/400 automation tools and
an ADSM administrative client but I don't have any specifics on that.

I'm sure someone else will chime in with more info and if you develop some
specific questions, please submit them to the forum.  I've found the forum
to be very helpful (frequently more helpful than IBM) in resolving how-to
issues.

Dennis Schaffer
Mutual of Omaha
<Prev in Thread] Current Thread [Next in Thread>