Well that was painful but I found the problem after digging around on my
own.. The "Backing up DB2 using Tivoli Storage Manager" redbook lacks a step
in the section "Chapter 6 : Backing up DB2 UDB on the Sun Solaris Platform".
I closely followed the steps there and did it on two different DB2
installations with the same result.. Eventually after trying to troubleshoot
and running out of ideas I read Appendix A "Quick start/checklist for
configuration" which has a Sun Solaris section. After following the steps in
there I found a section which was never mentioned in the main Installation
section in chapter 6.. mainly this at the end of the quick start:

- Get db cfg for DBNAME.
- Update db cfg for DBNAME using TSM_PASSWORD NULL. (Similar
syntax for other Tivoli Storage Manager parameters. NULL causes the
parameter to be reset to nothing.)


db2 => get db cfg for ds50

relevant portion of output:

TSM management class                    (TSM_MGMTCLASS) = DB2_MGMTCLASS
 TSM node name                            (TSM_NODENAME) = ds-s0-99-1
 TSM owner                                   (TSM_OWNER) = admin
 TSM password                             (TSM_PASSWORD) = *****

db2 => update db cfg for ds50 using TSM_PASSWORD NULL
DB20000I  The UPDATE DATABASE CONFIGURATION command completed successfully.
DB21026I  For most configuration parameters, all applications must
disconnect
from this database before the changes become effective.

db2 => update db cfg for ds50 using TSM_MGMTCLASS NULL
DB20000I  The UPDATE DATABASE CONFIGURATION command completed successfully.
DB21026I  For most configuration parameters, all applications must
disconnect
from this database before the changes become effective.

db2 => update db cfg for ds50 using TSM_OWNER NULL
DB20000I  The UPDATE DATABASE CONFIGURATION command completed successfully.
DB21026I  For most configuration parameters, all applications must
disconnect
from this database before the changes become effective.

db2 => update db cfg for ds50 using TSM_NODENAME NULL
DB20000I  The UPDATE DATABASE CONFIGURATION command completed successfully.
DB21026I  For most configuration parameters, all applications must
disconnect
from this database before the changes become effective.

db2 => backup db ds50 use tsm

Backup successful. The timestamp for this backup image is : 20020531164955

db2 =>

Thus why it was gripping RC 2032 complaining about ownership.. it was a
parameter in DB2 all along..

Regards,

Gerald Wichmann
Senior Systems Development Engineer
Zantaz, Inc.
925.598.3099 (w)

-----Original Message-----
From: William F. Colwell [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 31, 2002 2:32 PM
To: [EMAIL PROTECTED]
Subject: Re: DB2 backup problem..

Gerald,

The return codes for tsm products that use the api are in the
api folder, include folder, dsmrc.h file.  TDPO and db2/udp use the
api.  In this case rc=2032 means --

#define DSM_RC_NO_OWNER_REQD       2032 /* owner not allowed. Allow default
*/

Exactly what to change to fix this?  I have no idea.

Hope this helps,

Bill

At 01:27 PM 5/31/2002 -0700, you wrote:
>I can't find this return code anywhere.. anyone know what this means?
>DB2 7.1 EE, TSM 4.2.2 server/client..  both boxes are solaris 2.8
>
>
>db2 => backup db ds50 online use tsm
>SQL2062N An error occurred while accessing media
>"/opt/db2udb/sqllib/adsm/libadsm.a". Reason code: "2032".
>
>db2 => ? sql2062n
>
> SQL2062N An error occurred while accessing media "<media>".
>          Reason code: "<reason-code>"
>
>Explanation:  An unexpected error occurred while accessing a
>device, file, TSM or the vendor shared library during the
>processing of a database utility.  The following is a list of
>reason codes:
>
>
>1 An attempt to initialize a device, file, TSM or the vendor
>shared library failed.
>
>2 An attempt to terminate a device, file, TSM or the vendor
>shared library failed.
>
>other If you are using TSM, this is an error code returned by
>TSM.
>
>The utility stops processing.
>
>User Response:  Ensure the device, file, TSM or vendor shared
>library used by the utility is available and resubmit the utility
>command.  If the command is still unsuccessful, contact your
>technical service representative.
>
>
>
>$ ls -l /opt/db2udb/sqllib/adsm/libadsm.a
>-r-r-r-1 bin bin 93664 Apr 17 2001 /opt/db2udb/sqllib/adsm/libadsm.a
>
>
>
>Regards,
>
>Gerald Wichmann
>Senior Systems Development Engineer
>Zantaz, Inc.
>925.598.3099 (w)

----------
Bill Colwell
C. S. Draper Lab
Cambridge Ma.

Reply via email to