We have over 20 Windows 2000 Cluster servers. On all of these servers we have
to create 2 sets of all the services. One for the local drive and one for the
cluster. We have never run into the issue you are speaking of. We use the
dsmcutil command to create all our servers via scripting. The only issue I
have ever seen is that if you don't use the short 8.3 name for the path for
"/clientdir" then you can have problems.
I'm not sure if this will help but here is an example of what we use.
ex:
"C:\Program Files\Tivoli\TSM\Baclient\DSMCUTIL" Install /name:"TSM Central
Scheduler" /node:%COMPUTERNAME% /clientdir:C:\Progra~1\Tivoli\TSM\Baclient
/optfile:C:\Progra~1\Tivoli\TSM\Baclient\dsm.opt /pass:%COMPUTERNAME%
/startnow:no /autostart:no
One thing I have noticed is if you ever create services on a cluster you must
ensure that you create them adding the /clustername and /clusternode options.
Also, you have to use the /clusternode:no for the services you create that
aren't for the cluster. Finally you also have to make sure that you create the
cluster services first. If you don't do this correctly you will get errors but
they aren't all as clear as I would like.
Paul Fielding <[EMAIL PROTECTED]> wrote:
Several years ago I noticed an interesting behavior when installing multiple
client scheduler services on a server. A ticket was opened with IBM and the
final word came back that there was indeed a bug, the apar was opened, and we
were told it would be resolved. This week I've encoutered the same situation,
so I'm wondering if anyone has also noticed this behavior? I no longer have the
apar number of the original ticket, so I can't check to see the apar's status.
When installing a scheduler service (with apropriate cad, etc) you must supply
the dsm.opt file fo the service to use. For the first nodename on the server,
this is typically the Tivoli\TSM\baclient\dsm.opt file. When installing the
second set of services for an alternate nodename, you must supply an alternate
dsm.opt file.
If you run a dsmadmc -console while starting the CAD, you may notice that, when
the scheduler service contacts the TSM Server, it touches the server twice.
Under normal circumstances, this is just something I shrugged off as an
'interesting' thing.
However, after the second service instance is installed, when starting up the
CAD, I noticed that the the first of those two connections was using the wrong
nodename - instead of connecting to the TSM server with the nodename of the
second service, it connected with the nodename of the first service. The second
connection attempt then proceeded to use the correct nodename. Not knowing
exactly what information is sent on each of those connections, I do not know
the implications of this.
Basically what was happening was that when the scheduler service first starts
it grabbed the default dsm.opt location, instead of using the dsm.opt file
defined for that service. By the time it makes it's second connection attempt,
it's read the correct dsm.opt file.
The temporary band-aid was to configure the first scheduler service to use a
*non-standard* dsm.opt - the result being that when the second service tried to
connect using the default location, it failed to find a dsm.opt file there, and
simply connected sucessfully on the second attempt, using the correct dsm.opt
file.
More recently, I've noticed that when this situation occurs, if you set the
first service to use a non-standard dsm.opt file, during the install process I
initially get an error message stating that the service 'Could not find
c:\Program Files\Tivoli\TSM\baclient\dsm.opt' , even though that's not the
dsm.opt file I told it to read. The service then goes and sucessfully installs.
*shrug*.
It doesn't appear to be causing any real grief, but I'm wondering if I'm the
only one seeing this behavior or not, and if anyone may know of any genuine
grief this could cause?
regards,
Paul
---------------------------------
Do you Yahoo!?
Yahoo! Search presents - Jib Jab's 'Second Term'
