Troubleshooting
Problem
The command "db2adutl query nodename
Cause
Design changes in DB2® Universal Database™ (DB2 UDB) Version 8 modified the behavior of the DB2ADUTL utility.
Resolving The Problem
Here are the basic differences from DB2 UDB Version 7 to DB2 UDB Version 8:
[Note that this can affect you more if you have a multi-partition database and want to see backup images and log files from a different partition in your database.]
In DB2 UDB Version 7, when you specified the node name in the db2adutl command, it would masquerade as that node. For example, the command db2adutl query nodename bar would only give you images in Tivoli® Storage Manager (TSM) from the node "bar".
In DB2 UDB Version 8, when you specify the node name in db2adutl command, it looks for images from your current node and from the node name you specified. One big difference is that it does not pretend to be the node that was specified in the command. Instead the connection is performed via the node you are running the command from. DB2 UDB will, however, list the images from the node specified. There is a catch here. You have to grant access privileges to the connecting node. A sample of the grant command is given in a later paragraph as part of the following example:
The database configuration (db cfg) in this example contains the following:
...
tsm_owner: asgreen
tsm_nodename: bar
tsm_password: ****
...
From the machine "bar2", the following command is issued: db2 backup db sample use tsm
In this situation, the image is created in TSM as coming from the node "bar" because that was the setting in the db cfg. If you then tried to query the images from "bar2" with the command db2 query nodename bar, you would not see them. If you went to the machine "bar" and ran the command db2adutl query, you would see the images (userid asgreen). If you then granted access to the images to the node "bar2", you could go back to the "bar2" machine and run the command db2adutl query nodename bar and see the images. To properly grant the privileges, you would need to run the following command:
db2adutl grant all on bar2 for all
You can obviously use other grant options to restrict access to the files from other machines if you wish (for example, by specifying specific userids, or specific databases in the above command). However, using this command would be a good test to prove that the GRANT works, and then you can use REVOKE followed by a new GRANT command to be more restrictive if you wish.
This behavior ties into the options DB2 UDB now supports in the BACKUP and RESTORE commands. In DB2 UDB Version 8, you can specify vendor options to the BACKUP and RESTORE commands. This can make cross-node backup and restore operations much easier. db2adutl in DB2 UDB Version 8 uses vendor options to convey the node name and owner to TSM.
Adding 'nodename' to the dsm.sys file is TSM's way of masquerading as another node.
Note that db2adutl does not look at the tsm_nodename parameter in the db cfg (although the backup utility still does - as shown in the above example). Therefore, even if you have set up a tsm_nodename in the db cfg, db2adutl will ignore this value. This is true for both DB2 UDB Version 7 and DB2 UDB Version 8, so this has not changed at all.
If you would still prefer that your node name is different from the actual TCP/IP hostname of your machine, then you will have to modify the dsm.sys file to add your node name. You will still have to register your hostname on the TSM server with the help of your TSM administrator, and then issue the db2adutl grant command for the TCP/IP hostname of the machine. Once these steps have been completed, you should then be able to issue the following command and have it complete successfully:
db2adutl query nodename <nodename> password xxxxx
..where <nodename> is the actual name you are using
Related Information
Was this topic helpful?
Document Information
Modified date:
16 June 2018
UID
swg21193256