Or the TSM client README file, which as a courtesy contains info on how to
subscribe and unsubscribe.
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.
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 2005-02-16
13:12:13:
> *smile* good question!!!!
>
> please read the monthly faq-list!
>
> Christian Demnitz
> mailto:christian.demnitz AT sinius DOT com
>
>
>
>
>
> Richard Seger <richard.seger AT ADIC DOT COM>
> Gesendet von: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
> 16.02.2005 21:04
> Bitte antworten an
> "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>
>
> An
> ADSM-L AT VM.MARIST DOT EDU
> Kopie
>
> Thema
> Unsubscribe
>
>
>
>
>
>
> How do I unsubscribe from this list?
>
> Thank you.
>
> Rich Seger
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager on behalf of Paul
Fielding
> Sent: Tue 2/15/2005 8:44 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Cc:
> Subject: Re: Bug? Using multiple client service
instances
> on Windows server
>
>
>
> Hi Andy,
>
> This is interesting. (Warning, long message)
>
> I tried doing this tonight on my XP SP2 system with
5.3.0
> client to
> demonstrate, since I don't have a server handy (will
try
> with 2003 server
> tommorow hopefully).
>
> I didn't see the behavior I previously described. But
> the behavior I did
> see was even more interesting. Below I'll describe the
> steps, in order. In
> the places where I break out into console log entries,
> this is the point
> during the install where that log item showed up in the
> console.
>
> Here's what I did:
> XP SP2 system with TSM 5.3.0 installed, no services
> installed.
> Two nodes - MATHILDA and BOOGA (hey, it's late)
> Two optfiles:
>
> dsm.opt, default location:
> nodename mathilda
> PASSWORDACCESS GENERATE
> schedmode prompted
> TCPSERVERADDRESS xxxxxxxxx
> schedlogretention 7
> errorlogretention 7
> MANAGEDSERVICES WEBCLIENT SCHEDULE
>
> dsm2.opt, default location:
> nodename booga
> PASSWORDACCESS GENERATE
> schedmode prompted
> TCPSERVERADDRESS xxxxxxxxx
> schedlogretention 7
> errorlogretention 7
> MANAGEDSERVICES WEBCLIENT SCHEDULE
>
> A. Install Acceptor #1
> 1. Startup GUI
> 2. Setup Wizard, check both install web client and
> scheduler
> 3. Install new acceptor
> 4. Named "TSM Client Acceptor" (default name)
> 5. default dsm.opt file (in the tsm\baclient directory)
>
> --console log--
> ANR0406I Session 6664 started for node MATHILDA (WinNT)
> (Tcp/Ip
> 142.163.252.132(4496)).
> ANR0403I Session 6664 ended for node MATHILDA (WinNT).
> --end console log--
>
> 6. http port 1581
> 7. Node MATHILDA, Pass MATHILDA, check validation
> 8. Start with System account, start manually
> 9. Named "TSM Remote Client Agent" (default name)
> 10. No revocation
> 11. Do not start now
> 12. Finish.
>
> --console log--
> ANR0406I Session 6665 started for node MATHILDA (WinNT)
> (Tcp/Ip
> 142.163.252.132(4510)).
> ANR0403I Session 6665 ended for node MATHILDA (WinNT).
> ANR0406I Session 6666 started for node MATHILDA (WinNT)
> (Tcp/Ip
> 142.163.252.132(4511)).
> ANR0403I Session 6666 ended for node MATHILDA (WinNT).
> --end console log--
>
> 13. Popup indicates installed.
>
> B. Install Scheduler #1
> 1. Install new scheduler
> 2. Named "TSM Client Scheduler" (default name), Local,
> with CAD
> 3. Select Acceptor defined above
> 4. leave log names blank to take default, uncheck event
> logging
> 5. Finish.
>
> --console log--
> ANR0406I Session 6667 started for node MATHILDA (WinNT)
> (Tcp/Ip
> 142.163.252.132(4516)).
> ANR0403I Session 6667 ended for node MATHILDA (WinNT).
> ANR0406I Session 6668 started for node MATHILDA (WinNT)
> (Tcp/Ip
> 142.163.252.132(4517)).
> ANR0403I Session 6668 ended for node MATHILDA (WinNT).
> ANR0406I Session 6669 started for node MATHILDA (WinNT)
> (Tcp/Ip
> 142.163.252.132(4518)).
> ANR0403I Session 6669 ended for node MATHILDA (WinNT).
> --end console log--
>
> 6. Popup indicates Installed.
>
> C. Install Acceptor #2
> 1. Startup GUI
> 2. Setup Wizard, check both install web client and
> scheduler
> 3. Install new acceptor
> 4. Named "TSM Client Acceptor - BOOGA"
> 5. dsm2.opt file (in the tsm\baclient directory)
>
> --console log--
> ANR0406I Session 6670 started for node MATHILDA (WinNT)
> (Tcp/Ip
> 142.163.252.132(4519)).
> ANR0403I Session 6670 ended for node MATHILDA (WinNT).
> --end console log--
>
> (note that it was Mathilda that just connected, not
> Booga, even though we
> just pointed it at the dsm2.opt file which has Booga as
> the nodename)
>
> 6. http port 1583
> 7. Node BOOGA, Pass BOOGA, check validation
> 8. Start with System account, start manually
> 9. Named "TSM Remote Client Agent - BOOGA"
> 10. No revocation
> 11. Do not start now
> 12. Finish.
>
> --console log--
> ANR0406I Session 6671 started for node BOOGA (WinNT)
> (Tcp/Ip
> 142.163.252.132(4534)).
> ANR0403I Session 6671 ended for node BOOGA (WinNT).
> ANR2841W Server is NOT IN COMPLIANCE with license
terms.
> ANR0406I Session 6672 started for node BOOGA (WinNT)
> (Tcp/Ip
> 142.163.252.132(4535)).
> ANR0403I Session 6672 ended for node BOOGA (WinNT).
> ANR2841W Server is NOT IN COMPLIANCE with license
terms.
>
> --end console log--
>
> 13. Popup indicates Installed.
>
> B. Install Scheduler #2
> 1. install new scheduler
> 2. Named "TSM Client Scheduler - BOOGA"
> 3. Select Acceptor defined above
> 4. select c:\temp\dsmched.log and dsmerror.log, no
event
> logging
> 5. Finish.
>
> --console log--
> ANR0406I Session 6678 started for node BOOGA (WinNT)
> (Tcp/Ip
> 142.163.252.132(4541)).
> ANR0403I Session 6678 ended for node BOOGA (WinNT).
> ANR0406I Session 6679 started for node MATHILDA (WinNT)
> (Tcp/Ip
> 142.163.252.132(4542)).
> ANR0403I Session 6679 ended for node MATHILDA (WinNT).
> ANR0406I Session 6680 started for node MATHILDA (WinNT)
> (Tcp/Ip
> 142.163.252.132(4543)).
> ANR0424W Session 6680 for node MATHILDA (WinNT) refused
-
> invalid password
> submitted.
> ANR0403I Session 6680 ended for node MATHILDA (WinNT).
> --end console log--
>
> (Note that first attempt is Booga, subsequent attempts
> Mathilda)
>
> 6. Popup Error message labeled DSM:
> Error 2 establishing TSM API session: .
> The password couldn't be authenticated with the TSM
> server
>
> 7. Click on OK, then new popup indicates Installed.
>
> ----------------------
> Output of dsmcutil list:
>
> Command: List Installed TSM Client Services
> Machine: MATHILDA(Local Machine)
>
>
> Installed TSM Client Services:
>
> 1. TSM Client Acceptor
> 2. TSM Client Acceptor - BOOGA
> 3. TSM Client Scheduler
> 4. TSM Client Scheduler - BOOGA
> 5. TSM Remote Client Agent
> 6. TSM Remote Client Agent - BOOGA
>
> 6 TSM Client Services were located.
>
>
> ----------------------
> Output of dsmcutil query /name:"TSM Client Acceptor -
> BOOGA":
>
> Connecting to service 'TSM Client Acceptor - BOOGA' ...
>
> Service Configuration/Status:
>
> Service Name : TSM Client Acceptor - BOOGA
> Logon Account : LocalSystem
> Start Type : Demand
> Current Status : Stopped
>
> TSM Client Service Registry Settings:
>
> Client Service Type = Client Acceptor Service
> Client Directory = "C:\Program
> Files\Tivoli\TSM\baclient\dsmcad.exe"
> Partner Service = TSM Remote Client Agent - BOOGA
> Cad Schedule Service = TSM Client Scheduler - BOOGA
> Options file = C:\Program
> Files\Tivoli\TSM\baclient\dsm2.opt
> Event Logging = YES
> TSM Client Node = BOOGA
> Comm Protocol = (value not currently set)
> Server = (value not currently set)
> Server Port = (value not currently set)
> HTTP Port = 1583
> Secure HTTP Port = (value not currently set)
> Web Ports = (value not currently set)
> Schedule Log = (value not currently set)
> Error Log = (value not currently set)
>
>
> ----------------------
> Output of dsmcutil query /name:"TSM Client Scheduler -
> BOOGA":
>
> Connecting to service 'TSM Client Scheduler - BOOGA'
...
>
> Service Configuration/Status:
>
> Service Name : TSM Client Scheduler - BOOGA
> Logon Account : LocalSystem
> Start Type : Demand
> Current Status : Stopped
>
> TSM Client Service Registry Settings:
>
> Client Service Type = Client Scheduler Service
> Client Directory = "C:\Program
> Files\Tivoli\TSM\baclient\dsmcsvc.exe"
> Options file = C:\Program
> Files\Tivoli\TSM\baclient\dsm2.opt
> Event Logging = NO
> TSM Client Node = MATHILDA
> Comm Protocol = (value not currently set)
> Server = (value not currently set)
> Server Port = (value not currently set)
> Schedule Log = c:\temp\dsmsched.log
> Error Log = c:\temp\dsmerror.log
> Cluster Enabled = (value not currently set)
> Cluster Name = (value not currently set)
>
> ------------------------
>
> If I start the service right now, the BOOGA service
> indeed connects using
> Mathilda's nodename (and Mathilda's password). Very
> odd. If I go back in
> and *edit* the service and change the node back to
BOOGA
> then it works fine
> after that. I won't bother with the console output at
> that point, because
> this is a whole different ballgame to the original
> behavior I was previously
> discussing.
>
> Tommorow I'll try this with a 2003 server to see if I
can
> demonstrate the
> original behavior I was talking about, but clearly
> something is amis
> regardless....
>
> regards,
>
> Paul
>
> ----- Original Message -----
> From: "Andrew Raibeck" <storman AT US.IBM DOT COM>
> To: <ADSM-L AT VM.MARIST DOT EDU>
> Sent: Tuesday, February 15, 2005 12:24 PM
> Subject: Re: [ADSM-L] Bug? Using multiple client
service
> instances on
> Windows server
>
>
> > Paul,
> >
> > I think you are referring to IC33355, which was
closed
> SUG. I do not know
> > the details behind the closure, but it was closed
that
> way presumably due
> > to the complexity (despite the seemingly simple
problem
> description) of
> > addressing the issue.
> >
> > I have not been able to reproduce your symptoms. Can
> you clarify a few
> > things for me?
> >
> > 1) Content of your two dsm.opt files
> >
> > 2) Output from "dsmcutil list"
> >
> > 3) Output from "dsmcutil query /name:xxxx" for each
> xxxx that shows up in
> > the dsmcutil list output
> >
> > 4) Admin console output that illustrates the problem
> >
> > 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.
> >
> > "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
wrote
> on 2005-02-14
> > 20:00:42:
> >
> >> I have things configured pretty much as you
describe,
> and I also use
> >> dsmcutil to create the services when using a
cluster-
> Way easier to
> > reduce
> >> mistakes since I can throw it into a batch file and
> run it on both sides
> > of
> >> the cluster. :)
> >>
> >> The issue I'm seeing, though, can be duplicated on a
> non-cluster.
> > (however
> >> the results seem to happen on some systems but not
> others) If you take a
> >> Windows 2000 or 2003 server and try the following:
> >>
> >> 1. Install a regular dsmcad, agent and scheduler
> service using the
> > default
> >> baclient\dsm.opt file.
> >> 2. create a second options file named something
> different such as
> > dsm2.opt
> >> 3. install a second set of services, named
> differently, and using the
> >> dsm2.opt, and using a different nodename from the
> first set. (ie. you
> > would
> >> use this if setting up a scheduler for an agent
> perhaps, or for a
> > cluster
> >> resource group).
> >> 4. before starting the dsmcad service, start up a
> console window
> >> (dsmadmc -console)
> >> 5. start dsmcad, wait the minute for the scheduler
to
> kick in
> >>
> >> What I see on the console (and in the actlog) is:
> >> - an inital connection using the correct (second)
> nodename, by the
> > dsmcad as
> >> soon as I start the service
> >> - 1 minute later, I see two more client connections
as
> the scheduler
> >> connects. the first connection uses the wrong
(first)
> nodename, the
> > second
> >> connection uses the correct (second) nodename.
> >>
> >> other than that, everything seems to work
> correctly.....
> >>
> >> Paul
> >>
> >> ----- Original Message -----
> >> From: "TSM_User" <tsm_user AT YAHOO DOT COM>
> >> To: <ADSM-L AT VM.MARIST DOT EDU>
> >> Sent: Monday, February 14, 2005 9:58 PM
> >> Subject: Re: [ADSM-L] Bug? Using multiple client
> service instances on
> >> Windows server
> >>
> >>
> >> > 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 <paul AT FIELDING DOT CA> 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'
> >> >
> >
|
