I don't think this got out the first time, at any rate
I decided to add some to it.  I would appreciate any=20
feedback you may have for improvement.

Here is a quick start guide for backing up db2 to
adsm.  This will be based on the AIX OS and the
3.7 TSM Api level.

1.  Install DB2
2.  Install TSM Api
3.  create a plain text file dsm.opt in /usr/tivoli/tsm/client/api/bin
 It only needs one line, the value for SERVERNAME is arbitrary, but
 must match the dsm.sys file
     SERVERNAME DB2
4.  create a plain text file dsm.sys in /usr/tivoli/tsm/client/api/bin
 It must contain at least the following.
     SERVERNAME DB2
     COMMMETHOD TCPIP
     TCPSERVERADDRESS xxx.xxx.xxx.xxx
     NODENAME DB2TSM
     PASSWORDACCESS GENERATE
5.  register the node DB2TSM on the TSM server
     It is recommended to create a new DOMAIN on the TSM server for this =
node.
     It needs only one management class with a copygroup that has the
     following retention settings.
     VEREXIST=3D1
     VERDELETED=3D0
     RETEXTRA=3D0
     RETONLY=3D0
6.  sign-on as root and cd to the db2 directory that contains the files
    db2adutl and dsmapipw.
7.  run the executable 'dsmapipw' follow the prompts.  It will ask for =
the
    current password, then for a new password, and confirmation of the =
new
    password.  It should report if it is successful.
8.  run the command 'db2adutl query' to confirm that the password file =
was
    correctly set.   If the command comes back and says no db2 objects =
found
    then it is working (you haven't done any backups yet).  You should =
be able
    to check the activity log on the TSM server to confirm that the node =
DB2TSM
    athenticated.
9.  You can now perform a backup using the command line or the db2 =
connect gui.
   =20
There is one point regarding password authentication=20
that is not explained really well.

Within the options file you can either specify passwordaccess
generate or password access prompt (dsm.opt for NT, dsm.sys
for the Unix flavors).

No matter which TSM password method you are using, these four
values are needed.  ADSM NODE, ADSM PASSWORD, ADSM MGMTCLASS,=20
ADSM OWNER.  These values can either come from=20
within the specific db2 database (db2 set db cfg .....),
or come from the options file and current logged on user.

If you are using password access generate, those values
come from the options file and current logged on user.
The values within the specific db2 database are NOT used.
The ADSM NODE comes from the NODENAME option in the options
file.  The ADSM MGMTCLASS comes from the options file or
goes to the default management class for the node.
The ADSM OWNER is only for the Unix variants and comes from
the user that is logged on to the OS and is performing the
backup(the instance owner, i.e. db2inst1).  The ADSM
PASSWORD comes from an encrypted file that had to
be previously created by running the utility that comes
with db2, DSMAPIPW.

The only time the values set within the specific db2 database=20
are used is when passwordaccess is set to PROMPT.  Note that=20
each db2 database in a given instance has it's own four adsm=20
values.  You must set these everytime for each database if
you are going to use passwordaccess prompt.

The only time PASSWORDACCESS PROMPT is required is when you=20
are performing a restore of a db2 database that was backed=20
up under a different unix user (ADSM OWNER).  This case is=20
when you are trying to restore a database backed up from a=20
different db2 instance (same machine or different) and want=20
to restore it to another db2 instance.  DB2 calls this a=20
redirected restore. =20

What helped me understand why you had to use PASSWORDACCESS prompt=20
is the following.  When a file or api object is backed up under Unix,=20
the owner of the object is sent as well.  Only the owner or a ROOT=20
user can restore that object.  In the case of a redirected restore=20
you have DB2 requiring you to be logged on as the unix user that=20
has authority to perform restores for that instance.  But in this=20
case you are trying to restore a db2 database that was backed up=20
to ADSM with a different unix owner.  So ADSM is requiring you to be=20
logged on as the unix user that initially performed the backup. =20
Since you can only be logged on once, and since DB2 and ADSM=20
require different users to be logged on, you have a conflict.
This is resolved by setting all the ADSM parameters within the=20
DB2 database that you are restoring to.  You then specify password=20
access prompt, and when you perform the restore, DB2 is happy=20
since your are logged on as the instance owner, and ADSM is=20
happy because it gets the ADSM NODE, ADSM OWNER, and ADSM PASSWORD, =20
from the db2 database that is being restored into.

Whew... Did I leave anything out?

James Thompson