RC 2221 means that there is an invalid option in dsm.sys or dsm.opt. If this is
not the case, then it might be an issue with the environment variables.

The following is an information APAR, II10103, that includes various tips for
configuring DB2/6000 and the ADSM API. Please be sure to check each item shown.

Andy Raibeck
IBM Storage Systems Division
ADSM Client Development
e-mail: storman AT us.ibm DOT com



This INFO APAR was created to document some hints and tips for
configuring the ADSM API for use with DB2/6000.

1) Verify that the ADSM API environment variables are configured
   correctly. Here is an example of how to set them up in the
   instance name's .profile file:

      export DSMI_DIR=/usr/lpp/adsm/bin
      export DSMI_CONFIG=/usr/lpp/adsm/bin/dsm.opt
      export DSMI_LOG=$HOME/sqllib/adsm

   Note that DSMI_CONFIG must point to the options file itself,
   not just the directory.

   DSMI_LOG is where dsierror.log will be written.
   '$HOME/sqllib/adsm' is just a suggestion... use whatever
   directory you want, as long as the instance name has write
   permission to the directory.

2) Install the latest client if you already haven't done so.

   (Note that 2.1.0.5 was the latest client level at the time
   of this writing, and should be considered the *minimal*
   level.)

3) DB2 used to install a copy of the API. It is an old copy and
   must be removed.

      a) In $HOME/sqllib/adsm look for 'dsmtca' and
         'libApiDS.a'. These are older versions of the API and
         should be removed (or renamed to *.old).

         NOTE: The API no longer uses the 'dsmtca' file. Rather,
               it uses 'dsmapitca', which is located in
               /usr/lpp/adsm/bin (or wherever the DSMI_DIR
               /usr/lpp/adsm/bin (or wherever the DSMI_DIR
               environment variable points to).

      b) There should be ONE and ONLY ONE symbolic link in the
         configuration, and that is for 'libApiDS.a'. If it is
         not already in there, cd to '/usr/lib' and create the
         link:

                 ln -s /usr/lpp/adsm/api/bin/libApiDS.a

         Scan the $HOME/sqllib directory and subdirectories for
         any other instances of 'libApiDS.a' and 'dsmtca' and
         make sure they are gone. Also check any other DB2
         installation directories for these files or symbolic
         links. Another directory worth checking is
         /usr/lpp/db2_02_01, as well as its subdirectories. If
         in doubt, you can scan the /usr filesystem for all
         occurrences of 'libApiDS.a' and 'dsmtca' with the Unix
         "find" command:

                 find /usr -name libApiDS.a -print
                 find /usr -name libApiDS.a -print
                 find /usr -name dsmtca -print

         A more thorough, though longer-running approach is to
         scan *all* file systems for these files:

                 find / -name libApiDS.a -print
                 find / -name dsmtca -print

         IMPORTANT: The main points here are that there must be
                    only TWO references to 'libApiDS.a' in the
                    DB2 instance name's search path:

                         /usr/lib/libApiDS.a
                         /usr/lpp/adsm/api/bin/libApiDS.a

                    The one in /usr/lib must be a symbolic link
                    to the actual file in /usr/lpp/adsm/api/bin.

4) PASSWORDACCESS GENERATE must be set. If your other ADSM
   clients do not use this option, create another SERVERNAME
   clients do not use this option, create another SERVERNAME
   stanza in dsm.sys and code PASSWORDACCESS GENERATE. Then
   create a special dsm.opt file (pointed to by DSMI_CONFIG)
   that has:

      SERVERNAME whatever   <== the servername in the new
                                dsm.sys stanza

   Please note that PASSWORDACCESS GENERATE will not work if
   NODENAME is specified in dsm.opt. Either use the machine's
   hostname as the node name, or code NODENAME in dsm.sys.

5) Make sure you can run the 'dsmapipw' and 'adsmqry' programs.
   If they are working, then everything should be all set.

   Note that you must be the root user to run 'dsmapipw'.

6) If you still can not run 'db2 backup', then check:

      a) Have you restarted the DB2 database engine since
         updating the DSMI_DIR, DSMI_CONFIG, and DSMI_LOG
         updating the DSMI_DIR, DSMI_CONFIG, and DSMI_LOG
         environment variables in .profile?

      b) How are you actually starting DB2? Do you issue
         'db2start' from the AIX command line? If you are
         running 'db2start' from a script, then most likely the
         environment variables are being lost. To test this,
         shut down DB2, and start it from the command line in
         the background. Then try 'db2 backup'. Does it work?

7) Make sure that everyone has 'read' access to the dsm.sys and
   dsm.opt files.

8) Make sure that the /usr/lpp/adsm/bin/dsmapitca has the 's'
   bit set. Use the command 'chmod u+s dsmapitca' to set it, if
   necessary. Permissions should be '-rwsr-xr-x'. 'root' must be
   the owner.

9) Make sure that dsm.opt has TAPEPROMPT NO.



Please respond to ADSM-L AT VM.MARIST DOT EDU

To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: ondemand database backup with ADSM

We are running ADSM 2.1.5 on AIX 4.2.1.. We have Ondemand installed.  Ondemand
says to use ADSM to backup their database.
Has any one out there done this??? We have tried but  we  have had no success.
The db2 error is SQL2062N  with reason code 2221.
Support is a lot of help