Upgraded CMOD/TSM from 8.5/6.2 to 9.5/7.1 - Can't get them to talk

[tjspencer2]

I've upgraded CMOD from 8.5 to 9.5 and TSM from 6.2 to 7.1 and can NOT get them to talk to each other.

Anything I try to do in CMOD that requires connecting to TSM fails.

If I try to load data my load fails with detail "ARS1157E Unable to store the object ...".

This will be followed by a session rejected - authentication message by TSM, as follows:

 2016-02-17 15:40:52.465383   ADMIN         57119   Error   No      429   TSM Error: ANS1025E (RC137)  Session rejected: Authentication failure
, Return Code=137, Reason=0, File=arssmsms.cpp, Line=1301  Srvr->btccmddbt001v.bok.com 10.50.97.23 non-SSL<-   

I have reset the password in TSM and can connect locally via dsmadmc client and have updated my storage set detail, but the error still occurs.

It's like the CMOD to TSM connection is looking at something else to authenticate the connection and it's failing.

[Alessandro Perucchi]

What version of CMOD are you using exactly?
V9.5.0.??

When you changed the password in TSM, did you change the password of the TSM user, or the TSM nodes? Because these are not the same...
In fact CMOD doesn't care about the user, but more on the node password.

Did you change something in the dsm.sys and the dsm.opt assigned to CMOD? Adding something like "password=generate" in the dsm.opt?

[Justin Derrick]

Can you post your configs?  dsm.opt / dsm.sys, ars.cfg, and do a report on the storage node?

Don't forget to obscure any passwords / user ids / hostnames for privacy.

[tjspencer2]

When I changed the password in TSM, I changed the nodename password - the one I was using to connect to TSM with.

I did this via update nodename password.

I've changed nothing in dsm.opt or dsm.sys.

[Alessandro Perucchi]

again which version of CMOD? and which version of the TSM client, with the fix pack please.

[Justin Derrick]

One last request...  When you're in TSM, and you do a 'query node', does it show that the User ID has an expired password?

Maybe consider posting a 'query system' or 'query server' from your TSM server as well.

[Alessandro Perucchi]

One question that has nothing to do with your current problem... you have put that in your ars.cfg file:

Code: [Select]

ARS_ORIGINAL_CODEPAGE=819

who told you to use that value of 819? the ARSDB command? Because, I have a lot of customer who have a database with codepage 819, and the arsdb -uv command was ALWAYS giving 923 and not 819, because the value code page 819 is deprecated and has been replaced by 923.
That's why CMOD will always give you that kind of value even when you have your database set to 819.

That's why I am really curious to know how you got this value of 819...


Back to your problem... I see nothing wrong with your settings.

Concerning the TSM Client / TSM API, did you installed the fixpack 7.1.2 or later? Since you said that you have the TSM client 7.1, which I suppose is 7.1.0.0.

I am asking, because all the installation/upgrade I've done, I've installed with my customer always the client 7.1.2 or later. Except for one of them, where we needed to keep the version 6.4.3 and I never experienced such problem as you describe. Therefore I am wondering if in your case you have that problem.

[tjspencer2]

The account doesn't show locked out when issuing a "q node" command in TSM dsmadmc.

Also, i can login to the interactive client.

My TSM Client version is 7.1.1.100.

The issue seems to be that CMOD is using a different userid/password combination when trying to access TSM than when I do it via interactive session (dsmadmc).

Is there a userid/psswd stash somewhere that CMOD is passing to TSM?

[tjspencer2]

Also our 819 value was provided by a vendor when we first installed CMOD at version 8.5.0.5.

So I should change that value to 923?

[Alessandro Perucchi]

Also our 819 value was provided by a vendor when we first installed CMOD at version 8.5.0.5.

So I should change that value to 923?

No don't change it, I was just curious, because nobody is using now 819 for new databases, it should be 923.
If it was so installed, don't touch it. Otherwise you might break something.
And for new database since CMOD V8.5 the default is UTF-8.... strange... there should be a reason, but I don't see why...

[Alessandro Perucchi]

The account doesn't show locked out when issuing a "q node" command in TSM dsmadmc.

Also, i can login to the interactive client.

My TSM Client version is 7.1.1.100.

The issue seems to be that CMOD is using a different userid/password combination when trying to access TSM than when I do it via interactive session (dsmadmc).

Is there a userid/psswd stash somewhere that CMOD is passing to TSM?

The "dsmadmc" command is not the test you should do, you should use "dsmc" command, otherwise it is worthless.
If the node is called  MYNODE, then try the command:

dsmc q filespace -virtualnodename=MYNODE

then you enter the login (normally that's the same as the node, and it should be the login in the storage set/storage node in CMOD)
then you enter the password.

If it works... then you got the correct user/pwd combination.

If it doesn't work, then you did something wrong with the modification of the password in tsm.

[tjspencer2]

This last command worked and the result was that TSM showed me all my filespace types and names.

[tjspencer2]

Just to make sure I'm entering this correctly, please see the attached StorageSet.png screenprint to see my CMOD configuration.

And see my tsm dsmc interface screenprint command and results.

[Alessandro Perucchi]

you did everything correctly...

except to upgrade the tsm client to a higher version... I cannot help you more than that :-( in that case the ticket to IBM is the only solution I might see...

have you try to install CMOD V9.5.0.3 ?? just for the sake of trying?

[tjspencer2]

So IBM is going to have a patch out and their recommendation is to use that.

I will try to upgrade my TSM client and see if that doesn't resolve the problem.