But keep in mind that the Bytes Transferred is not the same as amount of
data backed up. This is the total number of bytes transferred during the
session and includes any retries due to files changing and such. I used
these numbers once to tell a Domino administrator we were backing up almost
50GB of Domino data per night. He then proceeded to tell me that the
filespace was only 18GB and only 40% used at that! Turns out there was a
high rate of CHANGINGRETRIES using the B/A client on an active Domino
server. Had to eat crow on that one!

If you are using these numbers to forcast or identify heavy users, you
should then check to make sure you're not seeing high retry counts.

I'm not sure how you would go about getting only the amount of data that was
backed up and stored in TSM for that session

Bill Boyer
DSS, Inc.

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
Halvorsen Geirr Gulbrand
Sent: Monday, September 16, 2002 10:10 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Backup reporting


Hi,
I have a suggestion on how to achieve one consolidated report for TSM.
Unfortunately, I don't have the scripts (anymore), but one of my customers
made the same thing using PERL. Perl is sort of made for these things, and
what he did; He made a client-schedule in TSM to start the desired script,
which used FTP to collect dsmschedlogs from clients, query the tsm-server
for events and such, and finally let perl parse all files so it could be put
together in a (normally) one-page format. If we got errors on a client,
those errors were appended to the output-file at the end. The first page
would have a short description of last nights backup of the clients,
(completed,missed), how many errors, how many files&MB backed up.

I guess this didn't help much directly, it's just my 2 cents worth, that
might give you an idea on how to go about it. You could of course use some
scripting language you are comfortable with, kix?,rexx?,shell?,vb?

Rgds
Geirr G. Halvorsen



-----Original Message-----
From: Arty Ecock [mailto:ECKCU AT CUNYVM.CUNY DOT EDU]
Sent: 16. september 2002 15:30
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Backup reporting


Hi,

   We're trying to put together some TSM backup reports for our
Help Desk staff.  We're using something like

   SELECT * FROM EVENTS ...

and things like

   SELECT NODE_NAME, LASTACC_TIME FROM NODES

and

   SELECT NODE_NAME, FILESPACE_NAME, (CURRENT_TIMESTAMP-BACKUP_END) DAYS
   AS "Days_Since_Backup" FROM FILESPACES WHERE
   CAST((CURRENT_TIMESTAMP-BACKUP_END) DAYS AS DECIMAL) >= 30 ORDER BY
   "Days_Since_Backup"

   What we need is a single, consolidated report that lists all our
client nodes and the (real) status of the morning's backup run.
"Query Events" (and the Select * from Events ...) will tell us
if the scheduled backup was "Completed", "Missed", or "Failed".
>From our experience, "Completed" only means that the scheduled
command actually completed, not that it was truly successful.
By way of exmple, we use a scheduled command script to drive our
Domino TDP backups.  The script invokes the DOMDSMC command to
actually perform the backup.  DOMDSMC may fail miserably, but as
long as the invoking (scheduled) script completes, the status of
the backup shows "Complete".  (We now pass a bad RC from the script
if DOMDSMC returns a bad RC).

   For our Oracle TDP backups, I believe there is a way to issue
a SELECT against the Oracle (RMAN?) instance to determine the state
of the most recent backup.

   Our Help Desk needs to determine if a backup for a given node
actually completed successfully, and if it failed, they need to
determine the cause (all without having exceptional knowledge of
TSM).

   I'm sure this problem has been addressed by many sites in many
ways.  Our ideal solution would be a number of SELECTs, which we
could drop in a CGI script on some Web Server.

   Any words of advice?

Arty Ecock
CUNY/CIS - (212) 541-0956