I've seen scheduler stops with 3.7 (Solaris client, as well)... if the tcp
server address is wrong/not-defined, the client-scheduler stops (seems to be
sensitive to the specific connection error).
I've not seen false successes, lately; only saw them on ADSM ConnectAgents
(and other command-scripts), which got fixed with TDP & TSM. We look for
client completion messages, in addition to "q events", just to be sure (on
critical clients, like the Exchange data base backups). I did have a guy
not notice the date correctly (on the "q events"); if you're using
begind=-1 (like we do), you'll see the previous day's events as well as the
current - to capture jobs that run before *and* after midnight, you see TWO
instances of all jobs scheduled for after midnight.
False success should be reported to IBM; I've not seen that for a long
time... it would be disconcerting to find that! (False failures, yes; but
those have been fixed.)
Don France
Technical Architect - Unix Engineering/P.A.C.E.
San Jose, CA
mailto:dfrance AT pacbell DOT net
PACE - http://www.pacepros.com
Bus-Ph: (408) 257-3037
-----Original Message-----
From: John Monahan [mailto:JohnMonahan AT LIBERTYDIVERSIFIED DOT COM]
Sent: Wednesday, November 29, 2000 12:46 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Scheduled backup anomalies
I have TSM 4.1 on NT, both clients and server and have encountered some
strange issues and wondering if anyone else has experienced anything
remotely similar.
First, my TSM server was offline for an evening, so no backups ran. The
next morning my normal script ran to query events for the past evening's
backups to see if they were successful or not. The problem is, about 1/3
of my clients do report a status of "successful" even though the server was
offline. The other 2/3 show a status of "missed", as they should. I take
it querying events is not a reliable way of determining success of a
scheduled backup.
Second, the next night everything should have worked smoothly. All of the
clients who were in a "missed" state from the night before, stayed in the
"missed" state the next evening, even though the server was up and working
properly. All the clients that were "successful" were that again, but this
time they actually were successful. I had to restart the Scheduler service
on all of the missed clients to get them to work again properly. I have
further tested this situation with a test client. I would unplug the NIC
so the schedule would be "missed", and then plug it back in. The only way
to get it to work again was to restart the scheduler service. I don't
recall ever having to restart the scheduler service with version 3.7, even
though I did have missed schedules once in a while. This can be quite a
pain with a lot of clients.
Anyone?
===========================================
John Monahan
Network Administrator
Liberty Diversified Industries
(763) 536-6677
===========================================
|
