DSM.OPT and DSM.SYS "SERVERNAME"

GregE

ADSM.ORG Senior Member
Joined
May 12, 2006
Messages
2,089
Reaction score
31
Points
0
Website
Visit site
PREDATAR Control23

BA Client 5.4.1 on HPUX 11

Could someone explain the relationship between SERVERNAME in DSM.OPT and SERVERNAME and NODENAME in DSM.SYS?

In order for my backup to run properly, I have to have all three of these values the same. What is the reason for NODENAME and SERVERNAME in a DSM.SYS stanza? Why not just one or the other?

I changed the DSM.OPT SERVERNAME value to be equal to the one on DSM.SYS. This is not the nodename registered in TSM, so I added NODENAME to DSM.SYS and the backup wouldn't run unless the SERVERNAME in both files was the same as NODENAME in DSM.SYS.
 
PREDATAR Control23

Nodename is the only one that matters in this scenario really -
that and the IP address you define for the client & server in dsm.sys...

SErvername has to match up between the dsm.sys and dsm.opt file -
that is how TSM finds the "stanza" to read.
However, this SErvername value can be really anything you want it to be,
so long as the IP address of the server & client are correct, the backup will go where you need it to go...

Can you post an example of what you did so we can see?
Before & after / working & not working versions?

-Chef.
 
PREDATAR Control23

Remember you can have multiple options for connecting to multiple servers. If the node only connects to one server - yes it looks redundant.
 
PREDATAR Control23

Nodename is the only one that matters in this scenario really -
that and the IP address you define for the client & server in dsm.sys...

SErvername has to match up between the dsm.sys and dsm.opt file -
that is how TSM finds the "stanza" to read.
However, this SErvername value can be really anything you want it to be,
so long as the IP address of the server & client are correct, the backup will go where you need it to go...

Can you post an example of what you did so we can see?
Before & after / working & not working versions?

-Chef.

Sure, server hostname is RCH001 and registered TSM nodename is RCH0001-CAP

Setup as follows, the client backs up properly:
DSM.OPT
Servername RCH001-CAP

DSM.SYS
Servername RCH001-CAP
Nodename RCH001-CAP

**********************************
Setup as follows the client schedule is missed:
DSM.OPT
Servername RCH001

DSM.SYS
Servername RCH001
Nodename RCH001-CAPS
 
PREDATAR Control23

After any change to dsm.opt, you have to stop & restart the schedulers for it to be re-read in & picked up...

Let us know if that solved it...
-Chef
 
PREDATAR Control23

After any change to dsm.opt, you have to stop & restart the schedulers for it to be re-read in & picked up...

Let us know if that solved it...
-Chef

Just to be sure. The scheduler doesn't always run. DSMCAD is managing my scheduler startup. Does DSMCAD have to be restarted?
 
Last edited:
PREDATAR Control23

Hmmm...not sure about that - I don't use dsmcad to manage any of my schedulers...
Try it - why not :)

I tried it and launched dsmc sched manually. Didn't make a difference. If I remove NODENAME from the dsm.sys file, it will not access the TSM server. It tries to access with hostname only, which is not registered and I don't want it to be. But what's strange is that neither the dsm.opt nor dsm.sys SERVERNAME has the hostname itself listed. The registered node is RCH001-CAP, so why it's communicating with the TSM server as RCH001 I don't understand.

TSM server errors...
ANR0406I Session 20508 started for node RCH001 (HPUX).
ANR0422W Session 20508 for node RCH001 (HPUX) refused - node name not registered.

I have several Solaris servers that have no mention of NODENAME in their dsm.opt or dsm.sys files and there's never been a problem. I will say that on those servers, the FS is backed up by the hostname. Maybe that wouldn't work if it was something other than hostname? The Oracle TDPs on those Solaris servers are different registered names than the hostname, and each has it's own OPT file and DSM.SYS stanza. No problems there.

I'm confused.
 
Last edited:
PREDATAR Control23

You certainly do not need the nodename option, but as you are using it, the manner you have set it up seems fine.

without even waiting for a scheduled backup, the dsmc from the command line should attempt to log on with whatever nodename is selected in your dsm.sys.
 
PREDATAR Control23

If you have multiple stanzas, the nodename option tells you specifically which one you have this stanza set up for -
regardless of the servername info.

can you post the whole dsm.opt and dsm.sys files so we can look?
maybe that is on order here?

Setup as follows the client schedule is missed:
DSM.OPT
Servername RCH001

DSM.SYS
Servername RCH001
Nodename RCH001-CAPS

didn't you say the name was RCH001-CAP not CAPS -
or is that a typo above?
 
PREDATAR Control23

Greg.....Let's make it simple. Each stanza in the dsm.sy file - the Servername option - consider it an alias of the same TSM server which is you are connecting to - one what is going to support the applications needs thus leaving it isolated from the Default values. Use the Nodename option and its tcpclientaddress options to identify the TSM registered node - regardless if its the same server type - use this option to perhaps isolate the server's "function" or activity.
Ive been reading and - in regards to dsmcad and "dsmc sched" - Since there is a identified security breach at the moment with dsmcad - and since your server is HPUX - I would expect you to be running "dsmc sched &" command; even substantially using the -servername option of the same command line to isolate the backup's requirement. Yes dsmcad will work alone but you need to guarantee the dsm.sys schedmode is equal to prompted whereupon the TSM Server makes the initial contact with the node. You will see these attempts in the activity log as well as your dsmsched.log or dsmwebcl.log files.
Your connection refused errors messages are directly related to your node names you are attempting to connect with. Verify your character base - a typo - is a completely separate TSM registered node regardless of your intent.
I hope this clarifies things for you.
 
PREDATAR Control23

Hey Greg -

Did this work?

-Chef.

(I could swear I've done this before without success, but evidentally not)

Ok I set dsm.opt servername to RCH001

I set dsm.sys servername to RCH001 and dsm.sys nodename to RCH001-CAP

From the client, I ran "dsmc q sess" and it prompted for id and password and proceeded to contact the server as RCH001-CAP. I assume this testing of "q sess" is enough test to verify that this is a proper configuration and the backup tonight will also be successful.

That's stanza #1. Once I know this works as I expect, I can move to work on stanza #2 for a cluster scenario.
 
Last edited:
PREDATAR Control23

Cool. Try another stanza - and when you do 'dsmc q sess' and it prompts for a password, go to the TSM server and 'q se' to make sure it is indeed the node you want it to be before moving on.

Good luck -
-Chef.
 
PREDATAR Control23

servername in dsm.opt - this is needed if you have more than one tsm server and didnt change the servername. default is TSM

servername in dsm.sys - this should match the name you put in dsm.opt together with the ip address.

nodename in dsm.sys - this is the name you define when you register the client to the tsm server. it is important because this is the one used by the tsm server to communicate with the tsm server. they dont care about the ip address of the client.
 
PREDATAR Control23

Cool. Try another stanza - and when you do 'dsmc q sess' and it prompts for a password, go to the TSM server and 'q se' to make sure it is indeed the node you want it to be before moving on.

Good luck -
-Chef.

Ran a test with stanza #2, worked perfectly. As for a cluster setup, this client is being decommissioned in a couple months, moving to new hardware, so as far as a cluster goes, we're just going to run two schedulers per box (no need for dsmcad), not setting up as a cluster resource but instead just simply having TSM server connect via a virtual IP address, behind which these two clients reside. If client #1 is the active client, TSM contacts it via the virtual IP. If #2 is active, that's the one TSM contacts, also from the same virtual IP.

I appreciate everyone's help. Thank you. Seems simple now that it's done, but that servername/nodename was confusing at first for some reason.
 
Last edited:
PREDATAR Control23

hi

this thread helped me, too. Thanks to the community.

Greeetings
Roland
 
Top