Re: ADSM and DB2: Shared LIbrary Path and SQLUTIL

I am appending an information APAR, II10103, below. It contains a series of
tips for configuring the ADSM API for DB2/6000 on ADSM. While specific to
DB2/6000, some of the content applies to DB2/2 in a more general way (like the
business about setting up the environment variables properly, passwordaccess
generate, etc.).

Hope this helps,

Andy Raibeck
ADSM Level 2 Support

===========================


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
               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 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
   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
         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.





 ADSM-L AT VM.MARIST DOT EDU
 02-19-98 05:06 PM
Please respond to ADSM-L AT VM.MARIST DOT EDU @ internet

To: ADSM-L AT VM.MARIST DOT EDU @ internet
cc:
Subject: ADSM and DB2: Shared LIbrary Path and SQLUTIL

Hi, I am faced with a SQL2071N error msg when I try to backup (on DB2/2 or
DB2/6000) using ADSM.
This points to an "invalid shared library path". R&D on the shared library
path takes me to write-up on
SQLUTIL entries SQLU_ADSM_MEDIA and SQLU_OTHER_MEDIA values that must be
set so that
the DB2 API then hooks into ADSM. I have no luck determining where these
parameters can be set for DB2/2
or DB2/6000. This error is the same whether I try the DB2 Director or DB2
cmdline. I just started with DB2 with ADSM
setup on OS/2 and AIX.

Is there anyone out there able to help?

Regards

Campbell Esplin
Excalibur Business Solutions