Well, but don't you want to exclude those open/active/changing files from
nightly incremental processing ?
(so they won't show up as "failed" in the sched.log)
Like with oracle blah.dbf files... we want all those excluded.
DBAs process those with either TDP or by home grown scripts that put table
spaces in backup mode, then archive the associated .dbf file(s).
Also you can adjust your "changingretries" option, generally if it is just a
user doing something, you can catch things in a retry or two.

Dwight

-----Original Message-----
From: PINNI, BALANAND (SBCSI) [mailto:[EMAIL PROTECTED]]
Sent: Friday, July 27, 2001 11:24 AM
To: [EMAIL PROTECTED]
Subject: Re: Admin changes in last 2 years?
Importance: Low


Hi Cook
I have a question .If the script kicks off and checks dsmsched.log for fail
entry and
 files that are open or getting updated results in  failed to backup shows
as failed schedule
but its a success schedule.

-----Original Message-----
From: Cook, Dwight E [mailto:[EMAIL PROTECTED]]
Sent: Friday, July 27, 2001 11:11 AM
To: [EMAIL PROTECTED]
Subject: Re: Admin changes in last 2 years?


On the failed client schedules...
You could set a "postschedcmd" to run a script that does something like a
        grep -i fail sched.log | mail -s $(hostname)_bkup_failures
[EMAIL PROTECTED]
Here we have about 500 clients, mainly  big unix servers... we have a fleet
of unix admins and we make it their job to check their  backups.  We (the
TSM server admins) just don't have the time.  We provide a single web site
with a page of all "exceptions" to the previous days backups but beyond that
"it is not our problem"

Dwight

-----Original Message-----
From: Francisco Reyes [mailto:[EMAIL PROTECTED]]
Sent: Friday, July 27, 2001 8:56 AM
To: [EMAIL PROTECTED]
Subject: Admin changes in last 2 years?


I was away from ADSM/TSM for about two years.
On the last two weeks I have been re-organizing a setup I inherited.

I am wondering what has changed from the day to day admin functionality in
the last two years I was away.

I still don't see a way to see why an scheduled client job failed. Even
though I only have a handfull of clients I don't see why this
functionality is still missing. After all there are companies out there
backing up hundreds of nodes. I don't think it is practical for those
companies to go to each failed client.

Any improvements with point in time backup/restores? I see an
"imagebackup", but from reading the description doesn't make much sense to
me. It reads pretty much like the same thing as a selective backup.

Reply via email to