> Does anybody know what the fastest way is to solve this ?
You should contact IBM support and provide the Dr. Watson log files that
were created when the client crashed. You should also provide dsm.opt and
dsmerror.log. The folks in TSM support should be able to work with
development to analyze the problem and work toward resolution. If you want
to post them here, I can take a brief look; but at the same time, you
should still contact support.
If Dr. Watson is not the default debugger, then you need to run from the
command prompt:
drwtsn32 -i
(Even if Dr. Watson is the default debugger, it doesn't hurt to run the
above command again.)
Then run:
drwtsn32
This will bring up the Dr. Watson configuration dialog. The "Log File
Path" setting points to the directory where drwtsn32.log is created. You
can leave it as is, or change it to whatever you want (I set mine to
C:\DrWatson, then created the C:\DrWatson directory).
The "Crash Dump" setting points to the name of the user.dmp file to be
created at the time of the crash. You can leave it as is, or change it to
whatever you want (I set mine to C:\DrWatson\user.dmp).
"Number of Instructions" defaults to 10; I set mine to 20.
"Number of Errors To Save" defaults to 10; I leave mine set to 10.
"Dump Symbol Table", "Dump All Thread Contexts", "Append To Existing Log
File", and "Visual Notification", and "Create Crash Dump File" should all
be checked.
"Sound Notification" may be checked or not, depending on your personal
preference.
Click "OK" when you are done configuring Dr. Watson.
If you didn't have this configuration, you should make the changes I
suggested above. Recreate the crash problem, collect the docs, and report
it to IBM support.
Something else to try: can you run an incremental backup from the command
line?
dsmc i
If you can recreate the crash this way, then for the purposes of gather
documentation, this is the preferred method since you don't have to deal
with fiddling about with the scheduler.
For the machine where the scheduler doesn't start at boot time: is the
service set for automatic startup? If so, are any messages generated in
the dsmerror or dsmsched.log files? How about the NT Event Log: any
messages there? If you run this command from the ..\baclient directory,
what does the output look like:
dsmcutil query /name:yourschedulername
where "yourschedulername" is the name of the TSM scheduler service. If you
do not know the name, you can determine it by running:
dsmcutil list
In general, when starting out with TSM, I recommend a minimal options
file, using mostly defaults, until you have a running configuration. If
you have a heavily customized options file, try a basic configuration:
commmethod tcpip
tcpserveraddress yourtsmserveraddress
tcpport yourtsmport
nodename yournodename
passwordaccess generate
where "yourtsmserveraddress" is the TCP/IP address of your TSM server,
"yourtsmport" is the TCP/IP port (you only need this option if you don't
use port 1500), and "yournodename" is the name of the TSM client node.
Regards,
Andy
Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com
The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.
Wouter V <wouter-v AT EASYNET DOT BE>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
01/22/2002 00:49
Please respond to "ADSM: Dist Stor Manager"
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: Windows TSM-Client Crash
Hello,
We just introduced TSM in our environment. We are now backuping up
1 unix server and 12 Windows clients (Windows 2000 Server, SP2).
We are using TSM Server 4.2.1.9 on a Unix server (S7A) and use
TSM Client 4.2.1.20 on all the windows clients.
We use a 3583 Ultrium Tape Lib, with 2 drives.
Problem 1 :
Unfortunately we have problems with the TSM Client on 3 of our Windows
machines,
1 machine fails to start the TSM Scheduler service during boottime,
if we start it manually, it runs, but crashes several times during
backup.
(we do an "autorestart", if the service fails)
the other 2 machines always start the backup, but the client (tsm
scheduler) crashes after a certain time,
are amount of files. There is not really a fixed point where the service
crashes. If backup
is launched from the scheduler, dsmsvc.exe crashes, if we start the backup
manually with dsmc incr,
dmsc.exe crashes.
Does anybody know what the fastest way is to solve this ?
Problem 2 :
During migration from disk to tape, I can see (on the display) that the
2
tapedrives are not constantly writing data to
tape, it's always writing for a short period of time, waiting for a
longer
period, writing, and so on ...
Is this normal ? Is there anything I can check or do ? Shouldn't the
tapestreamers really stream data from disk ?
I know our situation is not ideal (the whole diskpool is on 1 disk), but
it is on another scsi-bus than the tapestreamers.
Thank you very much in advance (sorry for all my questions, but this is
just
my second TSM installation),
Wouter Verschaeve,
Unix System Engineer.
|
