downlevel client connections.doc.doc.doc
TRANSCRIPT
INSTALL AND MIGRATION
Downlevel Client Connections
Applicable version(s): Version 7, Version 5
Applicable platform(s): AIX
Abstract: Can you connect to a DB2 V5.2 database from a DB2 V7.1 client?
No. When you attempt such a connection, you will receive an SQL5048N error message.
DB2 clients can connect to servers that are two (2) levels up and to servers that are one
(1) level down.
For example, a DB2 Version 7 client can connect to a DB2 Version 6 database and will
be able DB2 Version 8 as well as the next full version after Version 8.
Error code DIA3202 on a DB2 V7 UDB Enterprise Edition Solaris machine
connecting to an AS400 database
Applicable version(s): Version 7
Applicable platform(s): Solaris
Abstract: Error code DIA3202 on a DB2 V7 UDB Enterprise Edition Solaris machine
connecting to an AS400 database
Symptom
Customer was receiving a DIA3202 and DB2 trap when they attempted to connect to an
AS/400 database
from a Solaris DB2 UDB EE V7.1 GA machine.
Possible cause
The customer had a DCS database entry, but in there database catalog they had
specified the host database
name instead of the DCS alias name. DB2 will sometimes trap if there is no DCS catalog
entry. Unlike most traps,
this trap occurs every time the customer tries to connect.
Action
This problem can be corrected by adding a DCS entry or correcting the DCS or DB
catalog entry.
Problems using the db2cfimp tool to import database and node directory
information
Applicable version(s): Version 7
Applicable platform(s): Solaris
Abstract: Problems using the db2cfimp tool to import database and node directory
information. This defect is fixed in FixPak 3 for DB2 Version 7.
Symptom
Problems using the db2cfimp tool to import database and node directory information
(created using the db2cfexp tool). If there are more database directory entries than
node directory entries, the db2cfimp tool will create additional entries in the node
directory so that each entry in the database directory has a unique entry in the node
directory associated with it.
Possible cause
This defect was introduced in the DB2 Version 7.1 GA version of the product. The
db2cfimp tool will not reuse entries in the node directory if more than one entry in the
database directory references the same entry in the node directory.
Action
1) The extra entries created in the node directory are correct so no action is required to
connect to any database.
2) If desired, the workaround is to manually remove the extra entries from the node
directory and recatalog the affected entries in the database directory.
3) This defect is fixed in FixPak 3 for DB2 Version 7.
Server Profile Import SQL5048 Error
Applicable version(s): Version 7
Applicable platform(s): Windows 2000, Windows 95, Windows 98, Windows NT
Abstract: Customer imported a server profile from DB2 connect server and is getting
SQL5048 error.
Symptom
Customer imported a server profile from DB2 connect server and is getting SQL5048
error.
Possible cause
The import in CCA was not detecting that this is a non- DRDA client, and was
catalogging the host node directly instead of through the DB2 Connect server.
Action
Customer should install APAR IY13343 (available in v.7.1 FP2 and higher)
Error code SQL1402 during authentication
Applicable version(s): Version 7
Applicable platform(s): Windows NT
Abstract: SQL 1402 error when attempting authenticate users, that exist on the domain
the server is a part of, on a DB2 server.
Symptom
SQL 1402 error when attempting authenticate users, that exist on the domain the server
is a part of, on a DB2 server .
Possible cause
The DB2 service was started under a local admin account that did not exist on the
domain controller. The DB2 service account must have a user level account on the
domain controller.
Action
If the DB2 service starts as a system account the domain user account is not necessary.
It is also possible to start the service with a Domain Admin account as long as the fully
qualified domain user name is used.
DB2 version 7.1 for Solaris is not supported on Sparc20
Applicable version(s): Version 7
Applicable platform(s): Solaris
Abstract: DB2 version 7.1 for Solaris is not supported on Sparc20
Symptom
During an installation of DB2 Connect Enterprise Edition Version 7.1 on a Sparc20
machine, an error
message states that the DB2 packages cannot be installed because of missing
prerequisites. The
prerequisite packages are UltraSparc packages.
Possible cause
UltraSparc or higher is the only supported platform for version 7.1.
Action
Refer to Installation notes and Readme for more detailed information about this
requirement.
Error message: DB221531E is returned after running db2mscs utility on an MSCS install on
IBM Netfinity.
Applicable version(s): Version 7
Applicable platform(s): Windows 2000
Abstract: Error message: DB221531E is returned after running db2mscs utility on an MSCS install
on IBM Netfinity.
Symptom
Error message: DB221531E Cannot obtain property for MSCS is returned after running
db2mscs utility on
a Microsoft Cluster Server (MSCS) install on IBM Netfinity. Other machines (for example,
Dell) do not return this error.
Possible cause
DB2 may be unable to obtain the drive letter from the resource name. If the disk
resource was created by MS cluster software,
DB2 calls the cluster API and is able to find the drive letter (example, Dell).
Action
Set the INSTPROF_PATH to explicitly point to the instance profile directory in the
db2mscs.cfg file by specifying:
INSTPROF_PATH=E:\DB2PROFS Your next recourse would be to consult the
Administration Guide for guidance on how to set up DB2 with MSCS. The db2mscs utility
must be run for each instance-owing machine. Please refer to the db2mscs example
configuration
file (db2mscs.ee or db2mscs.eee) to verify how the configuration should look after the
db2mscs utility is invoked.
The Administration Guide contains step-by-step instructions on how to run the utility.
I cannot find the 'db2imgr' command?
Applicable version(s): Version 7
Applicable platform(s): All Platforms
Abstract: In the IBM DB2 Universal Database for UNIX: Quick Beginnings Version 7, Chapter 8:
DB2 Post-installation Migration Tasks, it states "The db2imgr command checks that your instance
can be migrated." I cannot find the "db2imgr" command.
This is a typo. The name of the command is db2imigr, not db2imgr.
I examined 'db2imigr' and it does not call 'd2ckmig' !?
Applicable version(s): Version 7
Applicable platform(s): All Platforms
Abstract: The IBM DB2 Universal Database for UNIX: Quick Beginnings Version 7, Chapter 8: DB2
Post-installation Migration Tasks states that db2imigr calls the db2ckmig command to check that the
databases in the instance can be migrated. Does db2imigr explicitly call the db2ckmig command?
No. 'db2imigr' does not explicitly call 'db2ckmig', but it does achieve the same
functionality.
ODBC Driver Manager error "Driver does not support function (#0)" appears when importing a
table with a timestamp column from Microsoft Access
Applicable version(s): Version 6, Version 7
Applicable platform(s): Windows 2000, Windows 95, Windows 98, Windows NT
Abstract: ODBC Driver Manager error "Driver does not support function (#0)" appears when
importing a table with a timestamp column from Microsoft Access
Symptom
The error message, "Driver does not support function (#0)" appears from the ODBC
Driver Manager when importing a table with a timestamp column from Microsoft Access.
Possible Cause
Microsoft Access does not support the timestamp precision of DB2. You need to force
the driver to describe a time stamp column as a CHAR(26) column instead of an SQL
timestamp column.
Action
There are two ways to avoid getting this error message:
Configure the CLI driver to describe time stamp columns as CHAR(26), by specifying
the PATCH1 keyword to include the value 131072. Further details on how to set the
PATCH1 keyword can be found Here .
Optimize your database for Microsoft Access using the Client Configuration Assistant.
How to migrate a process from a test environment to a production environment
Applicable version(s): Version 6, Version 7
Applicable platform(s): AIX
Abstract:
Question
How do I migrate a process from a test database environment to a production database
environment? (The terms "test" and "production" used here are not related to the mode
constructs "development," "test," and "production.")
Answer
To migrate the process, simply convert the process by changing or copying the source
tables. With any conversion, be sure to test the steps in the process before and after
you convert the process.
1. If the production table definitions already exist in Data Warehouse Center, open the
step's Change Source notebook to change the source from the test table to the
production table. If the table definitions don't exist, copy the tables or import the
production source definitions first.
2. Create a new target for the production step. The step must be in development mode.
To create the new target, you can move the test table to the production warehouse,
copy the test table to a production table, or link to an existing production table.
3. If you did not move the table, then delete the link from the step to the test target
table, add the target table from the production warehouse, and link it with the step.
4. Check that the step is configured properly and test it again. The step is now
completely migrated and ready for scheduling.
If you want a test process and a production process, copy the production table
definitions and change the source as described in steps 2 through 4. When you change a
source or target table, always check that the columns are correctly remapped.
How do I resolve SQL0332 errors when accessing a DB2 for OS/390 database server.
Applicable version(s): Version 6
Applicable platform(s): Windows NT
Abstract: How do I resolve SQL0332 errors when accessing a DB2 for OS/390 database server.
You must set DB2CODEPAGE to a value that is compatible with the host SCCSID. Also,
there must be a row in the SYSIBM.SYSSTRINGS table that maps the two values in the
INCCSID OUTCCSID columns.
For more information on DB2CODEPAGE values, see the "National Language Support
Considerations" Appendix in any of the DB2 Connect Quick Beginnings books.
After receiving and formatting dumps on gateway, the formatted dump shows SQL30020 rc
124c (syntax error)
Applicable version(s): Version 6
Applicable platform(s): AIX
Abstract: After receiving and formatting dumps on gateway, the formatted dump shows SQL30020
rc 124c (syntax error)
Symptom
After receiving and formatting dumps on gateway, the formatted dump shows SQL30020
rc 124c (syntax error).
Possible cause
This is a probable defect on the OS/390 DRDA parser. The host states that it is being
sent a password that is too long
for the DDM architecture. DDM defines the password object as having a length between
1 and 255 bytes.
It is possible that a password is being sent that is 256 bytes or more, but more likely the
host is incorrectly seeing this
as a parsing error.
Action
Check the receive buffer to verify the host complaint that the password sent as part of
the
connection request is too long.
Error code SQL30082 rc=0 connecting to OS/390
Applicable version(s): Version 6
Applicable platform(s): AIX
Abstract: Error code SQL30082 rc=0 connecting to OS/390
Symptom
SQL30082 rc=0 when connecting to OS/390 from an AIX machine using SNA.
Possible cause
DDF must be restarted after updating the SYSIBM.LUNAMES in order for the change to
take effect.
Action
SYSIBM.LUNAMES must be updated with the LU of the DB2 Connect gateway whenever a
new gateway is added.
An alternative is to leave a blank row in SYSIBM.LUNAMES. If the connection to MF is
tcpip, update SYSIBM.IPNAMES instead.
DB2 version 6.1 run time client appears to be missing a lot of the bind files from the
SQLLIB/BND directory
Applicable version(s): Version 6
Applicable platform(s): Windows NT
Abstract: DB2 version 6.1 run time client appears to be missing a lot of the bind files from the
SQLLIB/BND directory
Symptom
The DB2 version 6.1 run time client appears to be missing a lot of the bind files from the
SQLLIB/BND directory. Consequently users are unable to perform utility binds during
installation
Possible cause
When installing from the DB2 run-time client CD the SQLLIB/BND directory contains only
the following files:
db2batch.bnd
db2clpcs.bnd
db2clpnc.bnd
db2clprs.bnd
db2clpsy.bnd
db2clpur.bnd
db2gpmap.bnd
db2rbind.bnd
db2spca5.bnd
db2uiddl.bnd
Action
This was done by design. The run time client application enabler (CAE) was designed to
be as small as possible. This fact implies that at least one machine will need to have the
Administration CAE or Server code on it so that the packages can be bound against the
remote database. Once this machine binds the packages then any of the run time
clients (at the same code level) will be able to access the packages and work properly.
Error SQL1090C occurs when trying to initiate the clp by typing db2 (or prefixing a command
with db2) after migrating from V5.2 to V.6.1.
Applicable version(s): Version 6
Applicable platform(s): AIX
Abstract: Error SQL1090C occurs when trying to initiate the clp by typing db2 (or prefixing a
command with db2) after migrating from V5.2 to V.6.1.
Symptom
Error SQL1090C occurs when trying to initiate the clp by typing db2 (or prefixing a
command with db2) after migrating from V5.2 to V.6.1.
Possible cause
Some links are still pointing to V5.2 libraries rather than those of V6.1.
Action
Run db2ln, which is located in the /usr/lpp/db2_06_01/cfg directory. This command
ensures that all the links for
DB2 libraries reference the correct version of DB2 (depending on the directory from
which you run the command -
i.e. db2_06_01 rather than db2_05_00).
Error message: SQL1031N is received when migrating an instance from Version 5 to Version
6.
Applicable version(s): Version 6
Applicable platform(s): AIX
Abstract: Error message: SQL1031N is received when migrating an instance from Version 5 to
Version 6.
Symptom
Error message: SQL1031N is received when migrating an instance from Version 5 to
Version 6.
All databases were uncatalogued during the migration. After recataloging and migrating
all databases
but one (the others are under /home/<instance_name>, while the one which fails is
under /db2asset), the error
message: SQL1031N is received on connect and migration.
Possible cause
The local database directory is corrupt or inaccessible, so attempts to connect or
migrate produced an error.
Action
The following workaround is recommended to solve the connection/migration issue:
1) Ensure the database is uncatalogued, and terminate is run.
2) Rename the SQL00001 and local sqldbdir to *.old.
3) Create a new database of the same name under the /db2asset path.
4) Verify the connection to the new database, and terminate.
5) Rename the new database's SQL00001 to *.new (or remove it altogether).
6) Rename the SQL00001.old back to SQL00001 (taking the place of the new one).
7) Migrate the database.
DIA4801A - data received for data type at DRDA AS did not match what was expected
Applicable version(s): Version 6
Applicable platform(s): Windows NT
Abstract: DIA4801A - data received for data type at DRDA AS did not match what was expected
Symptom
DIA4801A amount of data received for a data type at the DRDA application server did
not match the amount which was expected a dump has been generated.
Possible cause
The program was issuing a PREPARE with an SQL statement that exceeded 32767 bytes.
Action
DRDA will not accept SQL statements greater than 32767 bytes in length. This is a DRDA
standard. If the machine being connected to is not an EBCDIC machine then DRDA is not
required and DB2 will support an SQL statement up to 65535 bytes in length.
db2start hangs on Linux distributions built with glibc 2.1
Applicable version(s): Version 6
Applicable platform(s): Linux
Abstract: Why does db2start hang on Linux distributions built with glibc 2.1?
Both the initial release and FixPak 1 for DB2 Universal Database V6.1 for Linux are
incompatible with distributions of Linux built with the glibc2.1 library. These distributions
include Caldera OpenLinux 2.4, Red Hat 6.1, SuSE 6.4, and TurboLinux 6.0.
To correct this problem, you must install FixPak 2 or later for DB2 V6.1 for Linux. You
can download DB2 V6.1 FixPaks from
http://www-4.ibm.com/cgi-bin/db2www/data/db2/udb/winos2unix/support/
download.d2w/version61.
Once you have downloaded the FixPak, perform the following steps to successfully
install DB2 V6.1 for
Linux:
1. Install DB2 V6.1. Do not create any instances.
2. Install DB2 V6.1 FixPak 2 or later.
3. Create the DB2 instances. You can use /usr/IBMdb2/V6.1/install/db2setup to create
the DB2 instances and Adminstration Server instance.
What versions of DB2 Connect products are supported on Windows 2000?
Applicable version(s): Version 5, Version 6, Version 7
Applicable platform(s): Windows 2000
Abstract:
IBM is pleased to announce that DB2 Connect products have been extensively tested
under Windows 2000 with official support beginning with General Availability of Windows
2000 on February 17, 2000.
The following DB2 Connect products are supported on Windows 2000:
IBM DB2 Connect Personal Edition 6.1, 7.1
IBM DB2 Connect Enterprise Edition 6.1, 7.1
Version 5, Version 6 and Version 7 of DB2 Client Application Enablers (DB2 CAE) are
supported on Windows 2000.
Support for Windows 2000 is provided in multiple languages. The following language
versions of DB2 are supported:
English, French, German, Italian, Brazilian Portuguese, Spanish, Japanese, Korean,
Simplified Chinese, Traditional Chinese, Danish, Swedish, Norwegian, Finnish.
Additional Information
The above products run on Windows 2000 without any changes or fixes.
There are special considerations for users of DB2 v6.1 (or later) on Windows 95 or
Windows 98 who are upgrading to Windows 2000. The instructions for upgrading DB2
from Windows 95/98 to Windows 2000 can be found at the following URL:
http://www.ibm.com/software/data/db2/udb/udb-nt/windows2000/migration.html
Here are some other sources of information:
Official IBM Software site for Windows 2000:
http://www.ibm.com/software/is/mp/windows2000/
Official Microsoft Windows 2000 compatibility site (includes list of Windows 2000
compatible DB2 products):
http://www.microsoft.com/windows2000/upgrade/compat/search/default.asp
DB2 migrate after installing a fixpak on the new version of DB2.
Applicable version(s): Version 5, Version 6,
Applicable platform(s): All Platforms
Abstract: I installed the latest fipack for the newly installed version of DB2 before migrating the
instance(s). Do I update my instances using the db2iupdt command?
No, do not run db2iupdt in this situation. The updating of the instance(s) is done when
the instance(s) are migrated by running the db2imigr command.
No Authority to Create Sample Database or start DB2 - DB2 for Windows 95, Windows 98,
Windows 98SE
Applicable version(s): Version 5, Version 6
Applicable platform(s): Windows 95, Windows 98
Abstract: No Authority to Create Sample Database or start DB2 - DB2 for Windows 95, Windows 98,
Windows 98SE
Symptom
DB2 did not start at system startup. Cannot create the SAMPLE database from the First
Steps GUI.
Possible cause
1. Incorrect log in type. A secure log in is required.
"Windows" log in is mainly for utilizing a specific user's preferences,
such as the desktop environment. A secure network type log in, in which
groups can exist, is required to authenticate the user and
start DB2. This applies to Windows 95, Windows 98,and
Windows 98SE only.
2. Login and password greater than 8 characters.
3. Not logged on as a user with SYSADM authority.
4. DB2 service is not set to automatic in the Control Panel/Services
Action
Ensure that user ID and password are less than eight characters.
Go to network neighbourhood properties and change
the log in type to Client for Microsoft Networks. Logout and log back in as
as a user with SYSADMIN authority.
From the CLP issue the db2start command. DB2 Should start successfully.
From the CLP run the db2sampl command to create the sample database, or start First
Steps and
click on Create Sample Database.
From the Control Panel , Services Icon you can set the DB2 Service to Automatic.
It may be Disabled or Manual. If it is manual the user would have to issue a db2start
from the MSDOS Prompt
SQL0104N when issuing an outer join query from MS Access against DB2 MVS or OS/390
Applicable version(s): Version 5
Applicable platform(s): Windows 95, Windows NT
Abstract: SQL0104N when issuing an outer join query from MS Access against DB2 MVS or OS/390
Symptom
SQL0104N is received when issuing an outer join query from MS Access against DB2
MVS or OS/390 with the following message:
IBM CLI Driver DB2 SQL0104N "An unexpected token "(" was following "". Expected
tokens may include "<IDENTIFIER>".
SQLSTATE=42601 (#-104)
Possible cause
Applications like MS Access generate an outer join queries with a pair of extra
parenthesis. This syntax works against DB2 UDB servers, but is not supported by
DB2/MVS. Here is an example:
Query specified by user in MS Access:
SELECT ABC1.XYZ1, ABC2.XYZ1 FROM EFGH_ABC1 AS ABC1 LEFT JOIN EFGH_ABC2 AS
ABC2 ON ABC1.XYZ1 = ABC2.XYZ1 WHERE ( ABC1.XYZ1 > 456);
MS Access modifies the above query and sends the following to the ODBC(CLI) driver:
SELECT "EFGH"."ABC1"."XYZ1", "EFGH"."ABC1"."NAME","EFGH"."ABC2".
XYZ1","EFGH"."ABC2"."NAME" FROM
{oj "EFGH"."ABC1" LEFT OUTER JOIN "EFGH"."ABC2" ON ("EFGH"."ABC1"."XYZ1" =
"EFGH"."ABC2"."XYZ1" ) }
WHERE ("EFGH"."ABC1"."XYZ1" > 456 )
It is the "(" and ")" after "ON" that causes DB2 on OS/390 to return SQL0104.
Action
Apply the latest Version 5 FixPak for your platform, available from:
http://www-4.ibm.com/cgi-bin/db2www/data/db2/udb/winos2unix/support/
download.d2w/report
and set PATCH2=19 in the DB2CLI.INI.
Here is information on configuring PATCH2 settings. With this patch setting, the DB2
CLI/ODBC driver parses the outer join SQL query and modifies it to a syntax supported
by DB2 for OS/390 (or MVS).
Alternatively, you may use the pass through option of MS Access as a workaround.
Problem connecting directly to a host via a DDCS application (DB2 UDB V5.x for Windows NT)
Applicable version(s): Version 5
Applicable platform(s): Windows NT
Abstract: Problem connecting directly to a host via a DDCS application (DB2 UDB V5.x for Windows
NT)
Symptom
You are running DB2 UDB V5.x for Windows NT and you attempt to connect directly to a
host via a DDCS application (not a gateway). This attempt to initiate DDCS
communication with the host fails.
Possible cause
Value of DB2DBMSADDR registry value may need to be modified.
Action
The default database manager shared memory address is 20000000 on Windows NT. If a
shared memory address collision occurs, this value can be modified to force the
database manager instance to lay its shared memory at a different address. Use the
DB2DBMSADDR registry value to assign an address value in the range of 20000000 to
B0000000 on Windows NT.
The value of DB2DBMSADDR is in hexidecimal format, without the preceeding 0x.
DB2DBMSADDR may be set using the db2set command, for example:
db2set DB2DBMSADDR=[new address value]
DB2 Connect hangs when doing a restart after a crash
Applicable version(s): Version 5
Applicable platform(s): AIX
Abstract: DB2 Connect hangs when doing a restart after a crash
Symptom
DB2 Connect hangs when doing a restart after a database crash. The db2diag.log
shows an error of 001b (27) being returned by AIX.
Possible cause
DB2 is attempting to create a file larger than the size permitted by the
operating system. The AIX return code means "file too large."
Action
Check that the DB2 instance owner has the AIX maxfilesize parameter set to 2 GB
instead of the 1 GB default.
The file size for the user can be checked in /etc/security/limits.
Receive SQL30081 when DB2ADMIN is logged into the Windows NT gateway. When the
Administrator is logged in, the connection works fine
Applicable version(s): Version 5
Applicable platform(s): Windows NT
Abstract: Receive SQL30081 when DB2ADMIN is logged into the Windows NT gateway. When the
Administrator is logged in, the connection works fine
Symptom
Receive SQL30081 when DB2ADMIN is logged into the Windows NT gateway. When the
Administrator is logged in, the connection works fine.
Action
Check that you don't have DB2DBDFT set in the user environment variables.
Creating an instance on an AIX 4.3 system returns the messages DBI1281 and DB21019
Applicable version(s): Version 5
Applicable platform(s): AIX
Abstract: Creating an instance on an AIX 4.3 system returns the messages DBI1281 and DB21019
Symptom
The messages DBI1281 and DB21019 "An error occured while accesing the directory "
are generated when trying to create a DB2 instance on an AIX 4.3 system using the
db2icrt command.
Possible cause
In AIX 4.3 this is a problem with the file and directory permission settings.
Action
For a temporary workaround, copy the /usr/lpp/db2_05_00/instance directory into the
instance's owner home directory and run the db2icrt command from the there.
Otherwise, apply AIX APAR IX74957 and complete the following steps:
1. Boot to service mode using a sysback tape or network boot image
2. Choose the option "Maintenance Shell" from the sysback main menu
3. getrootfs
4. Choose the hdisk\# that is part of the rootvg
5. Choose "Access this volume group and start a shell before mounting the filesystems"
(Option 2).
6. mount /dev/hd4 /mnt
7. mount /dev/hd2 /mnt/usr
8. cp /mnt/usr/bin/chmod /usr/bin
9. umount /dev/hd2
10. cd /mnt
11. chmod 755 usr
chmod 755 var
chmod 755 home
chmod 777 tmp
chmod +t tmp
Do a chmod 755 for each other filesystem within rootvg
12. sync;sync;sync
13. cd /
14. umount /dev/hd4
15. exit
16. reboot
After migration of instances from Version 2 to Version 5.2, user cannot run any db2
commands
Applicable version(s): Version 5
Applicable platform(s): AIX
Abstract: After migration of instances from Version 2 to Version 5.2, user cannot run any db2
commands
Symptom
After migrating DB2 instances from DB2 Version 2 to Version 5.2 on a UNIX system, the
user cannot run any DB2 commands and receives the following message:
0509-023 Symbol clp_api in db2 is not defined
Possible Cause
The environment profile for the instance(s) was improperly set. This can be causes by
mixing a .profile file from an early Version with a .profile file with the new Version.
Action
Make a new DB2 instance to get a good .profile file and make any changes necessary to
the migrated DB2 instance(s).
DB2START command fails with an SQLCODE of SQL1092n after DB2 UDB installed on
Windows 95.
Applicable version(s): Version 5
Applicable platform(s): Windows 95
Abstract: DB2START command fails with an SQLCODE of SQL1092n after DB2 UDB installed on
Windows 95.
Symptom
Running the DB2START command fails with an SQLCODE of SQL1092N, and reports that
"" does not have the authority to perform the command.
Possible cause
The user needs to be logged on to any user account with a user name of 8 characters or
less.
Action
Log off and then log on to an arbitrary user account with a user name of 8 characters or
less.
License comes up in try-and-buy mode, but a permanent license was installed correctly
Applicable version(s): Version 5
Applicable platform(s): AIX
Abstract: License comes up in try-and-buy mode, but a permanent license was installed correctly
Symptom
License comes up in try-and-buy mode. A permanent license was installed in the correct
location, and the links were working properly. The license file was valid.
Possible cause
The wrong license key was installed. In this case, db2entr.lic was used instead of the
correct db2eent.lic.
Action
Install the correct license key as described in the Quick Beginnings manual.
Using db2icrt and dasicrt produces error message: DBI1281E
Applicable version(s): Version 5
Applicable platform(s): HP-UX, Solaris
Abstract: Using db2icrt and dasicrt produces error message: DBI1281E
Symptom
When trying to create a DB2 instance and a DAS using db2icrt and dasicrt, respectively,
after installing DB2 UDB version 5.2 for the Solaris or HP platform,
the following message is generated:
Program name = db2idbm
Instance home dir = /export/home/db2d, Sysadm group = db2dgrp
Instance type = 2, Auth type = SERVER
DB21016E The Command Line Processor encountered a system error while
sending the command to the backend process.
Update DBM cfg SYSADM_GROUP errcode = 8
DBI1281E The database manager configuration file could not be initialized.
Possible cause
The kernel parameters do not match those specified in the Quick Beginnings manual.
Action
Refer to the Quick Beginnings manual, and update your kernel parameters to match
those suggested in the book.
SQL1096n on CREATE DATABASE after fresh installation of DB2 Universal Database
Applicable version(s): Version 5
Applicable platform(s): Windows 2000, Windows 95, Windows 98, Windows NT
Abstract: SQL1096n on CREATE DATABASE after fresh installation of DB2 Universal Database
Symptom
SQL1096n on CREATE DATABASE after fresh installation of DB2 Universal Database
Possible cause
If you receive an SQL1096n when you attempt to create a database after installing DB2
Universal Database V5 (or later),
chances are that you installed a DB2 Client (prior to V6, DB2 Clients were called "Client
Application Enablers" or CAEs), not a DB2 server.
DB2 Clients are designed to connect to databases on remote DB2 servers. You cannot
create a DB2 database on a local machine
with just a DB2 Client (or CAE) installed. To create a database on your local system, you
must install a DB2 server product.
Action
If you are unsure of which product you have installed, you can use the regedt command
to check the Windows registry.
You can also check the \sqllib directory for a nodelock file. If your system does not have
one, a CAE or Client is installed.
System hangs when trying to install DB2 UDB on OS/2 Warp Connect.
Applicable version(s): Version 5
Applicable platform(s): OS/2
Abstract: System hangs when trying to install DB2 UDB on OS/2 Warp Connect.
Symptom
System hangs when trying to install DB2 UDB on OS/2 Warp Connect.
Possible cause
Installing DB2 UDB on OS/2 Warp Connect with mobility load. The hang is caused by
NetBIOS
and APPC detection during the installation. MTPS fixpack 8415 or later is required before
installing DB2 UDB, but only 8120 was applied.
Action
Download MPTS Fixpack 8415 from the anonymous FTP site:
ftp://ps.software.ibm.com/ps/products/mpts/fixes/english-us/wr08415_conv
Apply the Fixpack and reinstall DB2.
Install hangs at 96% mark of installation.
Applicable version(s): Version 5
Applicable platform(s): Windows NT
Abstract: Install hangs at 96% mark of installation.
Symptom
Install hangs at 96% mark of installation.
Possible cause
The 96% point is where DB2 installs documentation, which can be a time consuming
process. If the userid is on a remote domain, the process can be further lengthened.
Action
It is normal for install to spend a lot of time at 96%. When applicable, faster access is
possible through domain re-routing.
DRDA applications still shown in the list applications output after force application command
issued on server
Applicable version(s): Version 5
Applicable platform(s): AIX
Abstract: DRDA applications still shown in the list applications output after force application
command issued on server
Symptom
When the force application command is issued on the server, DRDA applications like
QMF are list shown in the list applications output.
Possible cause
A problem with the DB2 DRDA code caused the interrupt for the force application to be
ignored on platforms like AIX and OS/2
The problem however does not manifest itself on Windows NT.
Action
The fix is already available in DB2 v6.1(GA). For DB2 v5.2, a fixpak released after
September 1999 will address the problem.
Unable to uninstall DB2 because uninstaller says that DB2 is still running
Applicable version(s): Version 5
Applicable platform(s): Windows NT
Abstract: Unable to uninstall DB2 because uninstaller says that DB2 is still running
Symptom
The user is unable to uninstall DB2 because the uninstaller says that DB2 is still running. The same
symptom may appear when trying to install a DB2 fix pak.
Possible cause
On Netfinity systems, Netfinity may have loaded a DB2 DLL.
Action
Turn off Netfinity and reattempt the uninstall.
db2icrt failing with SQL10007N
Applicable version(s): Version 5
Applicable platform(s): AIX, HP-UX, Linux, SCO, SINIX, Solaris
Abstract: db2icrt failing with SQL10007N
Symptom
When trying to issue the db2icrt command after installing DB2 Version 5 on a Unix
machine, the following message is generated:
SQL10007N: Message "-1390" could not be retreived. Reason code: 5.
Possible cause
The LANG environment variable located in the .profile file is improperly set.
Action
Issue the command export LANG=en_US, or edit the .profile file to set LANG=en_US.
Message SQL8007 apears when db2start is issued, indicating that some products are coming
up in try and buy mode.
Applicable version(s): Version 5
Applicable platform(s): AIX
Abstract: Message SQL8007 apears when db2start is issued, indicating that some products are
coming up in try and buy mode.
Symptom
Message SQL8007 appears when db2start is issued, indicating that some products are
coming up in try and buy mode.
Possible cause
Mistakenly installed license support for products not intend for use. Even though license
support was uninstalled,
message SQL8007 still appears. This is because the *.lvl files for unused products under
sqllib/cfg were not removed.
Action
Remove the *.lvl files in sqllib/cfg for unused products.
DB2 comes up in try and buy mode even though customer has a valid license.
Applicable version(s): Version 5
Applicable platform(s): AIX, Windows NT
Abstract: DB2 comes up in try and buy mode even though customer has a valid license.
Symptom
During the install of DB2 on AIX, the licence files were not created or updated
automatically by DB2 install program, and DB2 comes up in try and buy mode.
SQL8008N/SQL8007W is received on Windows NT.
Cause
Due to a defect in the ifor code in DB2 version 5.0 the link from /usr/lib/netls/conf to
/var/ifor is not created during product installation.
Action
This is a defect in the ifor product that has been fixed in DB2 Version 5.2. Version 5.0
customers should update to version 5.2 or use the following workaround for AIX.
- manually create the link for the nodelock file from usr/lib/netls/conf to /var/ifor .
This problem has been addressed in FixPak 3 on Windows NT platform. Apply the latest
DB2 FixPak for greater protection.
Message SQL8007 apears when db2start is issued, indicating that some products are coming
up in try and buy mode.
Applicable version(s): Version 5
Applicable platform(s): AIX
Abstract: Message SQL8007 apears when db2start is issued, indicating that some products are
coming up in try and buy mode.
Symptom
Message SQL8007 appears when db2start is issued, indicating that some products are
coming up in try and buy mode.
Possible cause
Mistakenly installed license support for products not intend for use. Even though license
support was uninstalled,
message SQL8007 still appears. This is because the *.lvl files for unused products under
sqllib/cfg were not removed.
Action
Remove the *.lvl files in sqllib/cfg for unused products.
DB2 comes up in try and buy mode even though customer has a valid license.
Applicable version(s): Version 5
Applicable platform(s): AIX, Windows NT
Abstract: DB2 comes up in try and buy mode even though customer has a valid license.
Symptom
During the install of DB2 on AIX, the licence files were not created or updated
automatically by DB2 install program, and DB2 comes up in try and buy mode.
SQL8008N/SQL8007W is received on Windows NT.
Cause
Due to a defect in the ifor code in DB2 version 5.0 the link from /usr/lib/netls/conf to
/var/ifor is not created during product installation.
Action
This is a defect in the ifor product that has been fixed in DB2 Version 5.2. Version 5.0
customers should update to version 5.2 or use the following workaround for AIX.
- manually create the link for the nodelock file from usr/lib/netls/conf to /var/ifor .
This problem has been addressed in FixPak 3 on Windows NT platform. Apply the latest
DB2 FixPak for greater protection.
db2start fails with SQL8000N
Applicable version(s): Version 5
Applicable platform(s): AIX
Abstract: db2start fails with SQL8000N
The db2icrt command hangs in function updt_dbmcfg
Applicable version(s): Version 5
Applicable platform(s): Solaris
Abstract: The db2icrt command hangs in function updt_dbmcfg
Symptom
The db2icrt command hangs in function updt_dbmcfg on Solaris.
Possible cause
There is a typo in the /etc/system file at the following line:
set msgsys:msginfo_msgseq = 16384
It should read:
set msgsys:msginfo_msgseg = 16384
(The 'q' should be a 'g'.)
Action
Correct the typo.
db2start fails with SQL8000N
Applicable version(s): Version 5
Applicable platform(s): AIX
Abstract: db2start fails with SQL8000N
Symptom
db2start fails with SQL8000N
Possible cause
The wrong DB2 filesets are installed
Action
Remove the wrong filesets.
Examples of wrong filesets could be:
db2_05_00.pext (support for EEE)
dlnk and dsrv filesets for datalink
db2fman.lvl from sqllib/cfg
"DB2 does not exist" message returned when trying to start the Command Line Processor,
even after running db2profile.
Applicable version(s): Version 5
Applicable platform(s): AIX
Abstract: "DB2 does not exist" message returned when trying to start the Command Line Processor,
even after running db2profile.
Symptom
"DB2 does not exist" message returned when trying to start the Command Line
Processor, even after running db2profile.
Possible cause
db2profile was not run correctly.
Action
Run db2profile with the following command: . ./db2profile.
Return code 105 returned when running setup.exe with arguments on a DB2 UDB for
Windows NT install.
Applicable version(s): Version 5
Applicable platform(s): Windows NT
Abstract: Return code 105 returned when running setup.exe with arguments on a DB2 UDB for
Windows NT install.
Symptom
Return code 105 returned when running setup.exe with arguments on a DB2 UDB for
Windows NT install. This affects all clients.
Possible cause
The maximum number of characters allowed for the arguments to setup.exe command
is 60. This is a limitation of the InstallShield product.
Action
Limit arguments to setup.exe to 60 characters or less. A new version of InstallShield will
allow 95 characters in FixPak 3 for DB2 UDB.
The db2start command returns SQL8007W. A valid license was placed in the nodelock file, but
the db2licd process did not exist when the instance was restarted.
Applicable version(s): Version 5
Applicable platform(s): AIX
Abstract: The db2start command returns SQL8007W. A valid license was placed in the nodelock file,
but the db2licd process did not exist when the instance was restarted.
Symptom
The db2start command returns SQL8007w, indicating that DB2 is in try-and-buy mode. A
valid license was placed in the nodelock file, but the db2licd process did not exist when
the instance was restarted.
Possible cause
The file system containing the instance /sqllib directory was NFS mounted, and the
NOSUID bit was set on the mount (/etc/filesystems). The /etc/filesystems or automounter
setting for NOSUID should be set to OFF, or db2licd will not be able to start because it
requires the ability to SUID.
Action
Check the db2licd program in /sqllib/adm for proper permissions. If the file system that
contains /sqllib is mounted, then also make sure the NOSUID bit for that file system is
OFF. If the NOSUID bit is ON, set it to OFF and re-mount the file system. The db2start
should then work properly with the license.
CICS runtime system needs file libdb2gmf.a, but it is missing in the .../sqllib/lib directory
Applicable version(s): Version 5
Applicable platform(s): AIX
Abstract: CICS runtime system needs file libdb2gmf.a, but it is missing in the .../sqllib/lib directory
Symptom
You are running DB2 UDB Enterprise Edition V5.0 for AIX. You are attempting to
construct the CICS runtime
system which requires the file libdb2gmf.a but this file doesn't exist in the ...sqllib/lib
directory.
Possible cause
The file libdb2gmf.a is part of the fileset called "adt.rte". This fileset is laid down when
the DB2 Application
Development Tools are installed as part of the Software Developer's Kit (SDK).
Action
Install the SDK and be sure to select the DB2 Application Developer's Tools.
After applying PTF U453782, the dasiupdt command fails with DBI1069e and DBI1122e. The
dasicrt command fails with SQL1093.
Applicable version(s): Version 5
Applicable platform(s): AIX
Abstract: After applying PTF U453782, the dasiupdt command fails with DBI1069e and DBI1122e.
The dasicrt command fails with SQL1093.
Symptom
After applying PTF U453782, the dasiupdt command fails with DBI1069e, unexpected error, and
DBI1122e, instance 'db2as' cannot be updated. The dasicrt command fails at the first db2 update
dbm cfg with SQL1093, the user is not logged on.
Cause
The errors are cause by an NIS magic cookie entry, ":!::::::", in the etc/passwd and
etc/security/passwd files. The entry for the DAS id must be above the magic cookie entry in these
files for it to be found.
Action
If NIS is no longer required, remove the NIS cookie from the /etc/passwd and /etc/security/passwd
files. If NIS is required, move the instance id's above the magic cookie, or, preferably, have the
customer consult with their AIX administrator.
SQL10013N message received when trying to do a db2admin start from the admin server
directory
Applicable version(s): Version 5
Applicable platform(s): AIX
Abstract: SQL10013N message received when trying to do a db2admin start from the admin server
directory
Symptom
You are running DB2 UDB V5 for AIX. When you attempt a db2admin start from the admin server
directory you encounter a message stating SQL10013N: The specified library "" could not
be loaded.
Cause
Your .profile may be executing the db2profile from an instance other than the admin server
instance.
Action
Check your .profile to see which instance is executing the db2profile. If necessary, change your
.profile so that the db2profile is executed for the admin server.
Installing DB2 UDB for NT on a BDC (backup domain controller) fails as a new id for the DAS
canot be created.
Applicable version(s): Version 5
Applicable platform(s): Windows NT
Abstract: Installing DB2 UDB for NT on a BDC (backup domain controller) fails as a new id for the
DAS canot be created.
Symptom
Installing DB2 UDB for NT on a BDC (backup domain controller) fails as a new id for the
DAS canot be created.
Possible cause
This is an NT restriction. The NT API NetUserAdd does not allow the addition of users
while on the BDC.
Action
The workaround is to create the id before installing DB2 UDB on the BDC.
db2icrt fails on AIX 4.2 with DB21015E and DBI1281E
Applicable version(s): Version 5
Applicable platform(s): AIX
Abstract: db2icrt fails on AIX 4.2 with DB21015E and DBI1281E
Symptom
DB21015E and DBI1281E ' database manager configuration file could not be initialized'
message is returned when creating an instance using db2icrt command on an AIX 4.2
system.
Possible Cause
The AIX 4.2 default was changed to disallow group and others to write to /dev/null.
Action
Set the /dev/null permissions to crw-rw-rw-.
Error SQL8001 (with no return code) occurs when trying to make a third connection to a local
database with DB2 Connect EE.
Applicable version(s): Version 5
Applicable platform(s): AIX
Abstract: Error SQL8001 (with no return code) occurs when trying to make a third connection to a
local database with DB2 Connect EE.
Symptom
Error SQL8001 (with no return code) occurs when trying to make a third connection to a
local database with DB2 Connect EE.
Possible cause
DB2 Connect EE allows only two connections to local databases. This is because DB2
Connect is only licensed for the
creation of a single database which is to be used for transaction management with host
and AS/400 database servers.
A DB2 server is the appropriate tool to facilitate and manage connections to local
databases. Meanwhile, DB2 Connect can
exist on top of the DB2 server to provide access to host databases.
Action
Install a DB2 server (ie DB2 UDB Enterprise Edition for AIX).
The DB2WOU3I.DLL file is not copied during installation on Windows 95. DB2 states that the
DLL is missing.
Applicable version(s): Version 5
Applicable platform(s): Windows 95
Abstract: The DB2WOU3I.DLL file is not copied during installation on Windows 95. DB2 states that
the DLL is missing.
Symptom
The DB2WOU3I.DLL file is missing after installing DB2 Client Application Enabler Version
5 on the Windows 95 operating system.
Possible cause
McAffee VShield 3.1 anti-virus software running the virus definition of June 15, 1998 will
mistakenly delete the DB2WOU3I.DLL file without reporting it as infected.
Action
Upgrade to the most recent virus definition.
The DB2 installation utility hangs when attempting to install any DB2 Version 5 products
Applicable version(s): Version 5
Applicable platform(s): OS/2
Abstract: The DB2 installation utility hangs when attempting to install any DB2 Version 5 products
Symptom
The DB2 installation utility hangs when attempting to install any DB2 Version 5 products
Possible cause
OS/2 MPTS is at a lower service level than required.
Action
Upgrade MPTS to FixPak 8415 (non-SMP machines) or FixPack 8503 (for SMP machines).
DB2IDROP command returns reason code 13
Applicable version(s): Version 5
Applicable platform(s): AIX
Abstract: DB2IDROP command returns reason code 13
Symptom
db2idrop returns reason code 13.
Action
Apply PTF U457227. However, the execution of db2iupdt might return the following
message:
DBI1089E Error in saving current instance related information in the
/home/db05/sqllib/backup directory.
DB2 is simply backing up the current information to the sqllib/backup directory of the
instance. Essentially, the command it is issuing is /usr/lpp/db2_05_00/instance/db2iinfo
<instance name> \ <full path of insthome directory> sqllib/backup
Try logging on as the instance owner and executing this command. For instance if the
instance owner id is xv5 and the home directory for this instance is home/xv5 then the
command would be:
/usr/lpp/db2_05_00/instance/db2iinfo xv5 /home/xv5 sqllib/backup
A step by step procedure would be as follows:
su - xv5 or login directly as "xv5"
rename all of the files in the sqllib/backup directory.
issue the command: /usr/lpp/db2_05_00/instance/db2iinfo xv5 /home/xv5
sqllib/backup
check the directory for new files: db2systm.old , dbmcfg.lst
If this works without error, then the db2iupdt script should not fail on the DBI1089 Error,
since this is exactly how the script executes the command except that it does a su -c to
execute it. Therefore, if this works and the script still fails, try executing other
commands with su -c to make sure that works, then try
login as root.
rename files in /home/db05/sqllib/backup
issue: /usr/bin/su xv5 -c /usr/lpp/db2_05_00/instance/db2iinfo xv5 \ /home/xv5
/home/xv5/sqllib/backup
check the backup directory for the new files.
If all of the above works well then the db2iupdt should not be failing with DBI1089.
If there are further problems with the scripts, do NOT use set -x. Rather search the script
for setopts="+x" and change it to setopts="-x" If there is not a setopts parameter in the
script, then you can use set -x.
db2icrt fails on AIX 4.2 with DB21015E and DBI1281E
Applicable version(s): Version 5
Applicable platform(s): AIX
Abstract: db2icrt fails on AIX 4.2 with DB21015E and DBI1281E
Symptom
DB21015E and DBI1281E ' database manager configuration file could not be initialized'
message is returned when creating an instance using db2icrt command on an AIX 4.2
system.
Possible Cause
The AIX 4.2 default was changed to disallow group and others to write to /dev/null.
Action
Set the /dev/null permissions to crw-rw-rw-.
Error SQL8001 (with no return code) occurs when trying to make a third connection to a local
database with DB2 Connect EE.
Applicable version(s): Version 5
Applicable platform(s): AIX
Abstract: Error SQL8001 (with no return code) occurs when trying to make a third connection to a
local database with DB2 Connect EE.
Symptom
Error SQL8001 (with no return code) occurs when trying to make a third connection to a
local database with DB2 Connect EE.
Possible cause
DB2 Connect EE allows only two connections to local databases. This is because DB2
Connect is only licensed for the
creation of a single database which is to be used for transaction management with host
and AS/400 database servers.
A DB2 server is the appropriate tool to facilitate and manage connections to local
databases. Meanwhile, DB2 Connect can
exist on top of the DB2 server to provide access to host databases.
Action
Install a DB2 server (ie DB2 UDB Enterprise Edition for AIX).
The DB2WOU3I.DLL file is not copied during installation on Windows 95. DB2 states that the
DLL is missing.
Applicable version(s): Version 5
Applicable platform(s): Windows 95
Abstract: The DB2WOU3I.DLL file is not copied during installation on Windows 95. DB2 states that
the DLL is missing.
Symptom
The DB2WOU3I.DLL file is missing after installing DB2 Client Application Enabler Version
5 on the Windows 95 operating system.
Possible cause
McAffee VShield 3.1 anti-virus software running the virus definition of June 15, 1998 will
mistakenly delete the DB2WOU3I.DLL file without reporting it as infected.
Action
Upgrade to the most recent virus definition.
The DB2 installation utility hangs when attempting to install any DB2 Version 5 products
Applicable version(s): Version 5
Applicable platform(s): OS/2
Abstract: The DB2 installation utility hangs when attempting to install any DB2 Version 5 products
Symptom
The DB2 installation utility hangs when attempting to install any DB2 Version 5 products
Possible cause
OS/2 MPTS is at a lower service level than required.
Action
Upgrade MPTS to FixPak 8415 (non-SMP machines) or FixPack 8503 (for SMP machines).
Windows NT error with return code of 2226 after creating DB2ADMIN ID on Backup Domain
Controller.
Applicable version(s): Version 5
Applicable platform(s): Windows NT
Abstract: Windows NT error with return code of 2226 after creating DB2ADMIN ID on Backup
Domain Controller.
Symptom
Windows NT error with return code of 2226 after creating DB2ADMIN ID on Backup
Domain Controller.
Possible cause
Authentication is trying to take place on the Primary Domain Controller instead of the
Backup
Domain Controller.
Action
Set the DB2DMNBCKCTLR variable as outlined in the DB2 Version 5 Troubleshooting
Guide.
Install of DB2 UDB on Windows 95 appears to complete successfully, but the ifor exe's are not
installed in the ifor directory.
Applicable version(s): Version 5
Applicable platform(s): Windows NT
Abstract: Install of DB2 UDB on Windows 95 appears to complete successfully, but the ifor exe's are
not installed in the ifor directory.
Symptom
Install of DB2 UDB on Windows 95 appears to complete successfully, but the ifor exe's
are not installed in the ifor directory.
Possible cause
A problem with a LUM API.
Action
Apply latest FixPak.
Error SQL1090C occurs when precompiling MF COBOL applications that once worked on DB2
Parallel Edition V1.
Applicable version(s): Version 5
Applicable platform(s): AIX
Abstract: Error SQL1090C occurs when precompiling MF COBOL applications that once worked on
DB2 Parallel Edition V1.
Symptom
Error SQL1090C occurs when precompiling MF COBOL applications that once worked on
DB2 Parallel Edition V1.
Possible cause
The precompiler is at the wrong level.
Action
Run mkrts twice: once from /src/sql, again from /src/rts. Use the arguments specified in
the Quick Beginnings book, Chapter 9. After running mkrts twice, copy one file (it does
not matter which) to /usr/lib/cobol.
There is a typo in the example of the QB The example is missing one lpp in the directory
path.
Error SQL1403n occurs when trying to connect to MVS from DB2 Connect on AIX.
Applicable version(s): Version 5
Applicable platform(s): AIX
Abstract: Error SQL1403n occurs when trying to connect to MVS from DB2 Connect on AIX.
Symptom
Error SQL1403n occurs when trying to connect to MVS from DB2 Connect on AIX.
Possible cause
Userid was defined with 'user can login' = false in the security and user definition.
Action
Change the 'user can login' parameter in the security and user definition to true.
Loaded data in the database shows up garbled.
Applicable version(s): Version 5
Applicable platform(s): AIX
Abstract: Loaded data in the database shows up garbled.
Symptom
Loaded data in the database was showing up garbled.
Possible cause
The operating system where the database was residing had a different codepage than
the database itself.
As a result there was a translation between the operating system and the database
during the load.
Action
Ensure that the database and the operating system have the same codepages.
DBI1093E is returned when attempting to change group ownership during db2icrt
Applicable version(s): Version 5
Applicable platform(s): Solaris
Abstract: DBI1093E is returned when attempting to change group ownership during db2icrt
Symptom
DBI1093E is returned when attempting to change group ownership during db2icrt.
Possible cause
The /export/home directory is NFS mounted but not shared out to the DB2 Connect
server.
Action
Share out the directory to allow db2icrt to execute successfully.
It is possible to touch the files in the /export/home directory on the DB2 Connect server
before it is shared out. However, DB2 can not change the group until the directory is
shared out from the NFS server.
Error "NAT-3006: Invalid Certificate File Format" occurs when running "db2licinst
Applicable version(s): Version 5
Applicable platform(s): AIX
Abstract: Error "NAT-3006: Invalid Certificate File Format" occurs when running "db2licinst " to install
the license key.
Symptom
Error "NAT-3006: Invalid Certificate File Format" occurs when running "db2licinst
<licence_file>" to install the license key.
Possible Cause
The etc/filesystems or automounter setting for NOSUID was set to ON. This was done for
security reasons to prevent
unauthorized users from setting UID bits on programs. However, this also prevented
db2licd from starting as it requires
the ability to set UID bits on programs.
Action
If the filesystem that holds /sqllib is mounted ensure that the NOSUID bit is set to OFF.
Then re-mount the file system.
Also, check the db2licd program in /sqllib/adm for proper permissions.
DB2 Universal Database InstallSheild crashing
Applicable version(s): Version 5
Applicable platform(s): Windows NT
Abstract: DB2 Universal Database InstallSheild crashing
Symptom
DB2 UDB InstallSheild abends. Abend information may include: _ins0432._mp
DlgcacWinName 0x696cfc71.
Possible cause
The PATH environment variable is too long. InstallSheild can only handle a PATH
statement of 500 characters.
During the DB2 installation, approximately 50 chars are added to the PATH statement.
Action
Try typing 'path' at the command line to check the length of your PATH statement.
If it is too long, shorten it, complete the DB2 installation, and then restore the original
PATH after the installation is complete.
Inserts to CHAR columns on DB2/MVS are being padded by the @ symbol. For example,
"DB2" passsed to CHAR(8) becomes "DB2@@@@@".
Applicable version(s): Version 5
Applicable platform(s): AIX
Abstract: Inserts to CHAR columns on DB2/MVS are being padded by the @ symbol. For example,
"DB2" passsed to CHAR(8) becomes "DB2@@@@@".
Symptom
Inserts to CHAR columns on DB2/MVS are being padded by the @ symbol. For example,
"DB2" passsed to CHAR(8) becomes "DB2@@@@@".
Possible cause
This is probably a padding character mismatch.
Action
Fixpacks later than FixPak 6 contain a fix for this problem.
Another option is to check for MVS APARs PQ28632 and PQ22491, which address similar
padding issues that are specific to VARCHARs and stored procedures.
Error message: DB21019E An error occurred while accessing the directory ".." is received
with a db2icrt on SUN
Applicable version(s): Version 5
Applicable platform(s): Solaris
Abstract: Error message: DB21019E An error occurred while accessing the directory ".." is received
with a db2icrt on SUN
Symptom
Initially, error message: DBI1281E The database manager configuration file could not be
initialized
was received when creating an instance.
Next, the command su db2inst1 -c appears to hang, while /usr/bin/su db2inst1 works.
Ultimately, error message: DB21019E An error occurred while accessing the directory
".." is received with a db2icrt on Sun.
Possible cause
This is a problem with the Veritas Volume Manager.
Action
Contact Sun Microsystems for more information.
CHARacter data passed to DB2/390 stored procedures is being padded with x'40' characters
instead of x'20' characters.
Applicable version(s): Version 5
Applicable platform(s): AIX, HP-UX, Solaris, Windows 2000, Windows NT
Abstract: CHARacter data passed to DB2/390 stored procedures is being padded with x'40'
characters instead of x'20' characters.
Symptom
Character data passed to DB2/390 stored procedures is being padded with x'40'
characters instead of x'20' characters.
This symptom may also appear when an application that is calling a DB2 for OS/390
(510) stored procedure begins to get a +100 on
select calls within the stored procedure.
Possible cause
This may be a DB2/390 condition where the string is being padded with EBCDIC
character blanks instead of ASCII character blanks.
Action
DB2/390 APAR PQ28632 / PTF UQ34374 addresses this issue.
The DB2 Client Application Enabler install fails around 96% completion
Applicable version(s): Version 5
Applicable platform(s): Windows NT
Abstract: The DB2 Client Application Enabler install fails around 96% completion
Symptom
When installing the DB2 Client Application Enabler, the process fails at 96%
completion. The installation program then returns file copy errors such that
the program can not install the files. Some example of files include
template.mif and db2cmdw.dbg.
The DB2 Client Application Enabler is not installed successfully.
Possible cause
The PATH statement in the autoexec.bat file of Windows 95/98 is too long.
Action
Shorten the PATH statement in the autoexec.bat file and then reinstall the DB2
Client Application Enabler.
Download the latest Fix Pak from
http://www.software.ibm.com/data/db2/db2tech/indexsvc.html
Connecting to the host through SNA returns with error message: SQL0902 reason code 53
Applicable version(s): Version 5
Applicable platform(s): AIX, DOS, HP-UX, Linux, Macintosh, OS/2, SCO, SINIX, Solaris, Windows
3.1, Windows 95, Windows NT
Abstract: Connecting to the host through SNA returns with error message: SQL0902 reason code 53
Symptom
When connecting to the host with DB2 Connect version 5.2 through Systems Network
Architecture (SNA) I receive error message: SQL0902 reason code 53
Possible cause
Reason code 53 indicates a problem with the partner logical unit (LU) definition. The
transaction program (TP) name might not be defined in the CPIC Side Information.
Action
Ensure that the TP name is set in the Side Information Profile. If this value is set in
hexadecimal then be sure to set the variable HEX=YES
Receive SQL5043N when doing a DB2START on the Connect box. Also receive SPM0443 and
SPM0434 on DB2START. The return code from "ioctl(SET_CALLER_CHARACTERISTIC)" was
"1".
Applicable version(s): Version 5
Applicable platform(s): AIX
Abstract: Receive SQL5043N when doing a DB2START on the Connect box. Also receive SPM0443
and SPM0434 on DB2START. The return code from "ioctl(SET_CALLER_CHARACTERISTIC)" was
"1".
Symptom
Receive SQL5043N when doing a DB2START on the Connect box. Also receive SPM0443
and SPM0434 on DB2START.
The return code from "ioctl(SET_CALLER_CHARACTERISTIC)" was "1".
Possible cause
Group enuneration was failing on AIX 4.2.1.0. AIX return errno value for 'no permissions'.
Action
Upgrade AIX to latest maintenance any fixes for AIX 4.2.1. Restart SNA and DB2.
The installation of DB2 UDB version 6.1 fails on RedHat Linux and db2start hangs
Applicable version(s): Version 5
Applicable platform(s): AIX
Abstract: The installation of DB2 UDB version 6.1 fails on RedHat Linux and db2start hangs
Symptom
The installation of DB2 UDB version 6.1 fails on RedHat Linux and db2start hangs.
Action
A patch exists on:
ftp://ftp.software.ibm.com/ps/products/db2/tools/db2rh61fix.tgz (This is for DB2 UDB
version 6.1 FixPak 1.)
OR
ftp://ftp.software.ibm.com/ps/products/db2/tools/db2rh61gafix.tgz (This is for DB2 UDB
version 6.1 GA.)
Download and apply the fix during a DB2 install. All install instructions are packaged
with the archives.
Unable to connect to DB2 UDB using ODBC driver because of failure to load required DLLs.
Returned Windows NT system error 1157, DLL not found.
Applicable version(s): Version 5
Applicable platform(s): Windows NT
Abstract: Unable to connect to DB2 UDB using ODBC driver because of failure to load required
DLLs. Returned Windows NT system error 1157, DLL not found.
Symptom
Unable to connect to DB2 UDB using ODBC driver because of failure to load
required DLLs. Returned Windows NT system error 1157, DLL not found.
Possible cause
The sqllib subdirectory created by the initial installation was renamed without
updating the system Path environment variable accordingly, so the DLLs required
by the application could not be found.
Action
Update the system Path environment variable to include the \sqllib\bin
directory on the DB2 installation drive.
After installing clients using Thin Client, errors are received from Open Database Connectivity
(ODBC). The errors describe Driver Version Conflicts
Applicable version(s): Version 5
Applicable platform(s): Windows NT
Abstract: After installing clients using Thin Client, errors are received from Open Database
Connectivity (ODBC). The errors describe Driver Version Conflicts
Symptom
After installing clients using Thin Client, errors are received from Open Database
Connectivity (ODBC). The errors describe Driver Version Conflicts in odbccp32.dll and
other odbc*.dlls when ODBC applications are run. There is an indication that the
odbc.dlls are out of sync.
Possible cause
The Thin Setup is supposed to check the level of the ODBC Driver Manager on Thin
Client. Only if the level of the client is less than that in
\sqllib\thnsetup may it copy the .DLL files over.
In this case, the Thin Setup may not have tested the registry on Thin Client properly and
may have copied older .DLLs to the client. This is
probable if the client is at one of the more recent ODBC Driver levels, which could occur,
for instance, when Internet Explorer 5.0 is installed.
Action
APAR JR13922 available in Interim 11C addresses this issue.
A possible workaround is to copy the newest ODBC* files to C:\sqllib\thnsetup on the
codeserver. This will furnish the client with the most updated drivers.
Another way to resolve this problem is to apply the latest Microsoft Data Access
Components (MDAC) package.
Information on downloading the latest MDAC is available for download from:
http://www.microsoft.com/data/
A CICS application cannot bind unless CICS is brought down .
Applicable version(s): Version 5
Applicable platform(s): AIX
Abstract: A CICS application cannot bind unless CICS is brought down .
Symptom
Running a Visual Basic application through a Customer Information Control
Center (CICS) client activates a COBOL application on the gateway.
The COBOL application is activated through CICS/6000. The application
functions without incident, but when changes are made to the application
an error message: SQL0904 appears. The application can be rebound, but only
at the expense of bringing CICS/6000 down.
Possible cause
CICS maintains a connection to the server. On DB2 Multiple Virtual Storage
(MVS), the package lock will not release unless the CICS_AR thread
actually terminates.
Within a CICS region several cicsas (application servers) run. These are
long-running and multi-threaded processes. CICS loads and unloads
the applications which run within these cicsas processes. When an application
terminates, the cicsas process does not terminate, but instead
waits for the next program to be run under that process. The user application
where the DB2 calls are made runs in thread 1 of the process.
For performance reasons, the cicsas processes do not start and stop after a
program is run. The processes can, however, cycle using the
CEMT I TCLASS command. The cycling of cicsas processes can also be facilitated
by setting minimum and maximum servers and idle timeout
parameters in the region definition.
The CICS/6000 COBOL application, using DB2 Connect as a gateway, uses 2-phase
COMMIT, and a read-only transaction. The application cannot
be bound unless CICS is brought down. The reason for this is that a lock is
held on the package on the DB2 MVS server. Error message: SQL0904
indicates that the package is not available. Even when explicitly issuing a
COMMIT in the application the locks are not released.
It is possible that the application thread never dies; the connection remains
active, and until the connection dies, the lock on the package will not be
released. It is customary for the CICS application server to maintain
connections open for purposes of reuse.
CICS issues an xa_open when an application server (AS) is started. This
permits an application to be run under the AS. Once the AS has connected
to the database, the connection will remain active for the life of the AS,
rather than as long as the user's application is open. As a result, the
application
cannot rebind.
Note: DB2 MVS and DB2 UDB on AIX may behave differently from each other
concerning the release of locks held on packages.
Action
Three workarounds are provided below:
The recommended workaround is to set the TClass value for the minimum number
of application threads to 1 within the CICS
configuration (refer to updates from CICS for the most comprehensive
information in this regard). Set this value dynamically so that
idle threads can be kept open at your discretion.
Set the minapplicationserver configuration parameter to 1. This automatically kills off
idle connection threads.
Allow the AS process to timeout when there is no work for it to process.
This will terminate the connection, thus permitting a rebind.
Error message "SQL8000N valid product license not found", DB2 Connect Enterprise Edition
for AIX
Applicable version(s): Version 5
Applicable platform(s): AIX
Abstract: Error message "SQL8000N valid product license not found", DB2 Connect Enterprise
Edition for AIX
Symptom
You are running DB2 Connect Enterprise Edition on an AIX operating system. You
receive an error message stating "SQL8000N DB2START processing failed; a valid
product license was not found", even though DB2 was previously working.
Possible cause
You may not have specified db2conen.lic during db2licinst. This results in the
wrong licence key being written to the nodelock file.
Action
Compare the contents of the licence in the nodelock file to the key in the
db2conen.lic file on your product CD. If they are different you must run
db2licinst again specifying db2conen.lic. You can now restart DB2.
Possible cause
A problem may have been encountered during the installation of the DB2 product
licence.
Action
Install the required licence component filesets.
Copy DB2DIR/cfg/*.lvl into all V5 DB2 instances' sqllib/cfg directory, where
DB2DIR is the directory in which the DB2 product is installed.
Stop all active DB2 backend processes (db2bp).
Make sure the correct licence certificate is installed on your system.
db2setup failing on instance creation.
Applicable version(s): Version 5
Applicable platform(s): AIX
Abstract: db2setup failing on instance creation.
Symptom
You cannot create an initial instance or an administration server while
installing DB2 UDB on an AIX operating system using db2setup.
Possible cause
Permissions on the target installation directory (the directory where DB2 UDB
is going to be copied to) may not include read access for "group" and "others".
Action
Check permissions on the target directory and, if necessary, change permissions
(using the chmod command) to include read access for "group" and "others."
Cannot start the Information Center from within the Control Center when logged on to the
Novell network.
Applicable version(s): Version 5
Applicable platform(s): AIX
Abstract: Cannot start the Information Center from within the Control Center when logged on to the
Novell network.
Symptom
Cannot start the Information Center from within the Control Center when logged
on to the Novell network. A "You are already running Windows" error is
reported. Starting the Information Center from the command prompt using the
db2ic command works. Starting the Information Center also works if the network
logon is bypassed.
Possible cause
There were multiple PATH and SET PATH statements in the autoexec.bat file which
caused problems when running command.com for the Information Center. The order
of the paths within the PATH variable might also be a factor.
Action
Make sure only one SET PATH command is issued in the autoexec.bat file.
Microsoft error 2226 when installing DB2 on NT machine. Problem occurs on screen where
db2admin username is supposed to be created.
Applicable version(s): Version 5
Applicable platform(s): Windows NT
Abstract: Microsoft error 2226 when installing DB2 on NT machine. Problem occurs on screen
where db2admin username is supposed to be created.
Symptom
When attempting to install DB2 UDB for Windows NT, the user encounters an error
2226 even though they are a member of the Administrator group on this machine.
Possible cause
User names cannot be created on a BDC. They can, however, be created on the
primary domain controller.
Action
Create the DB2ADMIN username on the primary domain controller before installing
UDB, then synchronize the primary and backup domain controllers. Reattempt the
installation.
For further information on NT domain controllers, see the DB2 UDB
Troubleshooting Guide --> Chapter 2, "Troubleshooting the DB2 UDB Server" -->
Troubleshooting Tips --> User Authentication
Installing licences with the Nodelock Administration Tool returns error NAT30000, corrupt
nodelock file. Starting DB2 returns SQL8007W, DB2 in try and buy mode.
Applicable version(s): Version 5
Applicable platform(s): Windows NT
Abstract: Installing licences with the Nodelock Administration Tool returns error NAT30000, corrupt
nodelock file. Starting DB2 returns SQL8007W, DB2 in try and buy mode.
Symptom
Installing licences with the Nodelock Administration Tool returns error
NAT30000, corrupt nodelock file. Starting DB2 returns SQL8007W, DB2 in try
and buy mode.
Possible cause
The nodelock file was corrupted.
Action
Create a new nodelock file by following these steps:
Rename the corrupt nodelock file in the ifor\ls\conf directory to nodelock.bak.
Start the Nodelock Administration Tool.
Import all licenses. This creates a new nodelock file.
Reboot the machine.
Run db2start.
Setup Initialization Error occurs (rc=105) when running "setup.exe" with arguments greater
than 60 characters.
Applicable version(s): Version 5
Applicable platform(s): Windows NT
Abstract: Setup Initialization Error occurs (rc=105) when running "setup.exe" with arguments greater
than 60 characters.
Symptom
Setup Initialization Error occurs (rc=105) when running "setup.exe" with arguments
greater than 60 characters.
Possible cause
setup.exe allows only 60 characters for the arguments of the setup command.
This is a limitation of the Install Shield product.
Action
Apply FixPak 3 or later.
When version 5.2 CAE is installed on NT Terminal Server various problems are encountered.
Applicable version(s): Version 5
Applicable platform(s): Windows NT
Abstract: When version 5.2 CAE is installed on NT Terminal Server various problems are
encountered.
Symptom
When version 5.2 Client Application Enabler (CAE) is installed on Windows NT Terminal
Server various problems are encountered.
When logged on with a local administrator userID, the ability to connect and run Call
Center Agent (CCA) is unimpaired.
However, when a non-administrator userID is used, CCA does not run, nor do tasks work.
Furthermore, the Command Line Processor (CLP) fails to work.
Possible cause
Changes were made to code in DB2 UDB version 6.1 which enabled the installation of
CAE on Windows NT Terminal Server.
These changes were not in place prior to version 6.1 so there is no guarantee CAI will
install or work on a Terminal Server on version 5.2.
Further Explanation
Below is the URL where you can download version 6.1 client at FixPak 4 level of code.
There are two different clients on version 6.1: Runtime client and
Admin client. The Runtime is a subset of Admin without the GUI tools. Both Runtime and
Admin can be installed.
ftp.software.ibm.com/ps/products/db2/fixes/english-us/db2ntv61/client
There is a Readme here with information on where to find detailed installation and
configuration instructions. Additional configuration
is not necessary for this to be operational on the NT Terminal Server.
Installing a Server Node Type (DB2 UDB PE/EE) on top of a Client Node Type (DB2 Connect
PE, DB2 CAE) does not prepare the DB2 instance to listen for inbound requests (Service is
not created).
Applicable version(s): Version 5
Applicable platform(s): Windows 95
Abstract: Installing a Server Node Type (DB2 UDB PE/EE) on top of a Client Node Type (DB2
Connect PE, DB2 CAE) does not prepare the DB2 instance to listen for inbound requests (Service is
not created).
Symptom
Installing a Server Node Type (DB2 UDB PE/EE) on top of a Client Node Type (DB2
Connect PE, DB2 CAE)
does not prepare the DB2 instance to listen for inbound requests (Service is not
created). The catalogued information is not lost.
Possible cause
The upgrade does not prepare the DB2 instance to listen for inbound requests.
Action
Workarounds are: drop/recreate the existing instance, create another instance after the
server product is
installed, or to install both products at the same time (Client and Server Node Types).
In DB2 UDB version 8, the node type will be automatically updated when a DB2 server
product
is installed on top of a DB2 client product).
Installing SDK for EEE server gives pre-requisites problem for ODBC.
Applicable version(s): Version 5
Applicable platform(s): AIX
Abstract: Installing SDK for EEE server gives pre-requisites problem for ODBC.
Symptom
You have installed DB2 UDB Enterprise-Extended Edition for AIX V5.0 (engine level 971007). You
are now attempting to install the Software Developer's Kit from a separate CD-ROM (using either
SMIT or installp), but you encounter a number of error messages related to pre-requisites for
db2_05_00.odbc, as well as other error messages. As a result, the SDK install fails.
Cause
Normally, the SDK is installed from its own CD-ROM. However, for DB2 UDB EEE V5.0 you must
install the SDK from the EEE CD-ROM as it includes fixes not found on the SDK CD-ROM.
Action
For this release install the SDK from the EEE CD-ROM.
The db2icrt command hangs in function updt_dbmcfg
Applicable version(s): Version 5
Applicable platform(s): Solaris
Abstract: The db2icrt command hangs in function updt_dbmcfg
Symptom
The db2icrt command hangs in function updt_dbmcfg on Solaris.
Possible cause
There is a typo in the /etc/system file at the following line:
set msgsys:msginfo_msgseq = 16384
It should read:
set msgsys:msginfo_msgseg = 16384
(The 'q' should be a 'g'.)
Action
Correct the typo.
Error message: DBI1091 appears when attempting to change permissions
Applicable version(s): Version 5
Applicable platform(s): AIX
Abstract: Error message: DBI1091 appears when attempting to change permissions
Symptom
Error message: DBI1091E: An attempt to change permissions for
/home/db2admn/sqllib/misc/db2uext2 failed appears when
attempting to change permissions for <INSTHOME>/sqllib/misc/db2uext2.
Possible cause
The copy of the version 2 userexit fails because it does not exist. Since the
/sqllib/bin/db2uext2.v2
still exists on the filesystem an attempt was made to copy the version 2 userexit.
The <INSTHOME>/sqllib/bin/db2uext2.v2 file exists, so it is assumed that
<INSTHOME>/sqllib/misc/db2uext2 also exists.
Note: The reference to /sqllib/misc/db2uext2 is found at the bottom of the inst_userexit
function.
The error message may indicate inappropriate ownership of the file or directory.
Action
Disregard the error message or remove the db2uext.v2 file before migrating.
DB2 for OS/390 PTFs required for native TCP/IP connectivity with DB2 Connect
Applicable version(s): Version 5
Applicable platform(s): AIX, DOS, HP-UX, Macintosh, OS/2, SCO, SINIX, Solaris, Windows 3.1,
Windows 95, Windows NT
Abstract:
Question
What levels of service are recommended for the OS/390 host products for native TCP/IP
connectivity with DB2 Connect?
Answer
Native TCP/IP connectivity to DB2 for OS/390 requires that the following products be
installed on the S/390 host:
OS/390 Version 1 Release 3 or later. (Version 2 Release 5 is recommended for best
performance and lowest host CPU consumption.)
DB2 for OS/390 Version 5.1
In addition to these minimal requirements a certain level of maintenance is required for
the OS/390 operating system, the S/390 TCP/IP product, and the DB2 for OS/390
product. These requirements are documented in the informational APAR II11164. Click
on the APAR to read the text. If you are unable to read the APAR text, point your web
browser to the DB2 for OS/390 Support web site at
http://www.software.ibm.com/data/db2/os390/support.html and search for this
APAR.
Why does the local database directory not migrate when trying to migrate from DB2 Version 2
to DB2 Version 6
Applicable version(s): Version 2, Version 6
Applicable platform(s): Windows 2000, Windows 95, Windows 98, Windows NT
Abstract:
Question
Why does the local database directory not migrate when trying to migrate from DB2
Version 2 to DB2 Version 6?
Answer
When a customer installs DB2 version 6.1 on top of DB2 version 2.x.y on Windows
95/98/NT, where the customer had local databases created within DB2 version 2.x.y,
there will be a problem with instance migration. The problem that will occur is, that the
local database directory will not be migrated. This means the database(s) that existed
on the machine from DB2 version 2.x.y will not be usable after DB2 version 6.1 is
installed, and will not be able to be migrated without performing a few steps first.
Work around
(Work around 1 is very strongly preferred, as work around 2 is very difficult to do)
1.
Before the installation of DB2 version 6.1, customers should be instructed
to back up the v2 database(s). Then, after the installation of DB2 version
6.1, the old database(s) can be restored, and the restore will migrate the
database.
or, if the customer did not handle this,
2.
After the installation for DB2 version 6.1 on top of DB2 version 2.x.y,
customers can be instructed to copy the existing database(s) to a
different directory. Then, the customer should create database(s) of the
same name after DB2 version 6.1 is installed. (This will create the local
database directory, at the version 6.1 level.) Then, the DB2 version 2.x.y
database(s) can be moved to the version 6.1 local database directory.
Finally, the database migration routine can be called to migrate each of
the old databases, and the migration will be completed.
This is a 'will happen' problem when migrating from DB2 version 2.x.y to DB2 version
6.1 GA, but will not happen when DB2 version 2.x.y is migrated to DB2 version 6.1
fixpack 1 or later.
EPFI205 message received when applying a fixpack via response file.
Applicable version(s): Version 2, Version 5
Applicable platform(s): OS/2
Abstract: EPFI205 message received when applying a fixpack via response file.
Symptom
User receieves the message EPFI205 "Product already installed" when applying a Fix Pak via
response file.
Action
Ensure command line parameter is /A:U (for ACTION UPDATE) and NOT the default of /A:I (ACTION
INSTALL).
Creating DB2 ODBC datasources programmatically
Applicable version(s): All
Applicable platform(s): All Platforms
Abstract: Can scripts be used to create DB2 ODBC data sources without end-users using DB2
Client Configuration Assistant (CCA) GUI utility?
DB2 ODBC data sources can be created by a sequence of commands, and, hence
through executable scripts. To create an ODBC datasource (or ODBC DSN) a script must
perform the following actions:
1. Catalog node
2. Catalog database
3. If the ODBC DSN is referring to a DB2 for OS/390, DB2/400, or DB2 for VSE and VM
database, cataloging DCS DATABASE may also be required
4. Catalog ODBC data source
For additional information consult DB2 Command Reference manual (available in soft
copy on the product CD-ROM, online at this web site, or may be installed on your
workstation if you chose to install product documentation with DB2) for the following
commands:
CATALOG TCPIP NODE
CATALOG DATABASE
CATALOG DCS DATABASE
CATALOG ODBC DATA SOURCE