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/[EMAIL PROTECTED] Internet e-mail: [EMAIL PROTECTED] 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" <[email protected]> wrote on 2005-02-16 13:12:13: > *smile* good question!!!! > > please read the monthly faq-list! > > Christian Demnitz > mailto:[EMAIL PROTECTED] > > > > > > Richard Seger <[EMAIL PROTECTED]> > Gesendet von: "ADSM: Dist Stor Manager" <[email protected]> > 16.02.2005 21:04 > Bitte antworten an > "ADSM: Dist Stor Manager" <[email protected]> > > > An > [email protected] > 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: [email protected] > 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" <[EMAIL PROTECTED]> > To: <[email protected]> > 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/[EMAIL PROTECTED] > > Internet e-mail: [EMAIL PROTECTED] > > > > 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" <[email protected]> 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" <[EMAIL PROTECTED]> > >> To: <[email protected]> > >> 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 <[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' > >> > > >
