History:
At what seems like random times and nodes we keep getting the same problem.
Suddenly a working backup schedule starts missing its backups and after examination we see that the TSM server is trying to to use the name of what ever collocation group the node belongs to instead of the node address.
Working backup:
09/03/2013 01:00:06 ANR2561I Schedule prompter contacting TOTSS02 (session
162545) to start a scheduled operation. (SESSION: 10)
Problem occurs:
09/04/2013 01:00:32 ANR2716E Schedule prompter was not able to contact client
TOTSS02 using type 1 (ot 1501). (SESSION: 10)
tsm: XXXXXXX>q node totss02 f=d
Node Name: TOTSS02
Platform: WinNT
Client OS Level: 6.01
Client Version: Version 6, release 4, level 0.0
Policy Domain Name: REDACTED
Last Access Date/Time: 09/05/2013 13:44:44
Days Since Last Access: <1
Password Set Date/Time: 03/05/2013 11:08:27
Days Since Password Set: 184
Invalid Sign-on Count: 0
Locked?: No
Contact:
Compression: Client
Archive Delete Allowed?: Yes
Backup Delete Allowed?: Yes
Registration Date/Time: 03/05/2013 11:08:27
Registering Administrator: ADMIN
Last Communication Method Used: Tcp/Ip
Bytes Received Last Session: 279.72 M
Bytes Sent Last Session: 48.78 M
Duration of Last Session: 1,248.00
Pct. Idle Wait Last Session: 58.41
Pct. Comm. Wait Last Session: 26.20
Pct. Media Wait Last Session: 0.00
Optionset: WINSTD
URL:
Node Type: Client
Password Expiration Period:
Keep Mount Point?: No
Maximum Mount Points Allowed: 1
Auto Filespace Rename : No
Validate Protocol: No
TCP/IP Name: TOTSS02
TCP/IP Address: 172.25.160.55
Globally Unique ID: 74.63.f4.10.85.7d.11.e2.ad.d4.00.50.56.83.00.20
Transaction Group Max: 0
Data Write Path: ANY
Data Read Path: ANY
Session Initiation: ClientOrServer
High-level Address:
Low-level Address:
Collocation Group Name: OT
/snip
As you can see, the nodes proper TCP/IP Address is shown, it's static and have been the same since before the node was added to the TSM server.
But by running these commands, I list the actual content of the addresses the TSM server uses when contacting nodes:
The above query shows this entry in SCHEDULE_NODE_ADDRESSES:
707 1 ot 1501
After setting TCPCLIENTADDRESS and TCPCLIENTPORT in the clients dsm.opt file and making a quick backup to force the TSM server to recognise the client changes the entry in SCHEDULE_NODE_ADDRESSES to:
707 1 172.25.160.55 1501
So, we have a workaround when the problem occurs, but the workaround itself might cause problems in the future for the nodes it's used on.
Other things we have tried are:
Restarting the TSM server has a small chance of resolving the problem, my estimate is that this helps 1 out of 10 times.
Restarting and running a manual backup from the client makes no difference.
Reinstalling the BA Client does not help.
No problems have been found with the dns servers.
The TSM server was installed back in 2010 with an early version of 6.x and it has been upgraded to 6.3.2.0 wich it currently runs. It made no difference to the problem that keeps occurring.
Has anyone else ever experienced this or a similar problem?
If so, Did you ever find it's cause and/or solution?
At what seems like random times and nodes we keep getting the same problem.
Suddenly a working backup schedule starts missing its backups and after examination we see that the TSM server is trying to to use the name of what ever collocation group the node belongs to instead of the node address.
Working backup:
09/03/2013 01:00:06 ANR2561I Schedule prompter contacting TOTSS02 (session
162545) to start a scheduled operation. (SESSION: 10)
Problem occurs:
09/04/2013 01:00:32 ANR2716E Schedule prompter was not able to contact client
TOTSS02 using type 1 (ot 1501). (SESSION: 10)
tsm: XXXXXXX>q node totss02 f=d
Node Name: TOTSS02
Platform: WinNT
Client OS Level: 6.01
Client Version: Version 6, release 4, level 0.0
Policy Domain Name: REDACTED
Last Access Date/Time: 09/05/2013 13:44:44
Days Since Last Access: <1
Password Set Date/Time: 03/05/2013 11:08:27
Days Since Password Set: 184
Invalid Sign-on Count: 0
Locked?: No
Contact:
Compression: Client
Archive Delete Allowed?: Yes
Backup Delete Allowed?: Yes
Registration Date/Time: 03/05/2013 11:08:27
Registering Administrator: ADMIN
Last Communication Method Used: Tcp/Ip
Bytes Received Last Session: 279.72 M
Bytes Sent Last Session: 48.78 M
Duration of Last Session: 1,248.00
Pct. Idle Wait Last Session: 58.41
Pct. Comm. Wait Last Session: 26.20
Pct. Media Wait Last Session: 0.00
Optionset: WINSTD
URL:
Node Type: Client
Password Expiration Period:
Keep Mount Point?: No
Maximum Mount Points Allowed: 1
Auto Filespace Rename : No
Validate Protocol: No
TCP/IP Name: TOTSS02
TCP/IP Address: 172.25.160.55
Globally Unique ID: 74.63.f4.10.85.7d.11.e2.ad.d4.00.50.56.83.00.20
Transaction Group Max: 0
Data Write Path: ANY
Data Read Path: ANY
Session Initiation: ClientOrServer
High-level Address:
Low-level Address:
Collocation Group Name: OT
/snip
As you can see, the nodes proper TCP/IP Address is shown, it's static and have been the same since before the node was added to the TSM server.
But by running these commands, I list the actual content of the addresses the TSM server uses when contacting nodes:
- db2 connect to TSMDB1
- db2 set schema TSMDB1
- db2 “select * from SCHEDULE_NODE_ADDRESSES”
The above query shows this entry in SCHEDULE_NODE_ADDRESSES:
707 1 ot 1501
After setting TCPCLIENTADDRESS and TCPCLIENTPORT in the clients dsm.opt file and making a quick backup to force the TSM server to recognise the client changes the entry in SCHEDULE_NODE_ADDRESSES to:
707 1 172.25.160.55 1501
So, we have a workaround when the problem occurs, but the workaround itself might cause problems in the future for the nodes it's used on.
Other things we have tried are:
Restarting the TSM server has a small chance of resolving the problem, my estimate is that this helps 1 out of 10 times.
Restarting and running a manual backup from the client makes no difference.
Reinstalling the BA Client does not help.
No problems have been found with the dns servers.
The TSM server was installed back in 2010 with an early version of 6.x and it has been upgraded to 6.3.2.0 wich it currently runs. It made no difference to the problem that keeps occurring.
Has anyone else ever experienced this or a similar problem?
If so, Did you ever find it's cause and/or solution?