INSTALL AND MIGRATION
Downlevel Client ConnectionsApplicable 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.