SAP Basis Tech Supports

Symptom

You are requested by a SAP tool or documentation (SAP note, upgrade guide) to check the consistency of your system with respect to VARCHAR FOR BIT DATA or to remove one of the following two inconsistencies:
Table fields with DDIC data type RAW, LRAW or VARC are defined incorrectly in the database. The DB2 data type VARCHAR instead of BITVARCHAR (VARCHAR FOR BIT DATA) is used.DB2 data type VARCHAR FOR BIT DATA is incorrectly used for a table column (e.g. of DDIC type CHAR).

Inconsistencies are reported by SAP tools on the following occasions:
DB2 specific check during the upgrade to SAP Releases >= 6.20 that reports the inconsistency (in PREPARE phase DBPREP_CHK)Client Copy completing with an error (Database object for … is inconsistent; Fields: Inconsistent with the runtime object)DDIC <-> Database consistency check (e.g. using report RUTMSJOB)Error message in the system log (transaction SM21)

Tables known to be possibly affected are:
ICNV30L BUT000 VARID DF50L
SWWLOGHIST DB2QLRUR DB2LRUR ICNV31L
SOOD DB2QLOTRS DB2LOTRS DB2QLODLK
SAPWLSFIHD DB2QLOTHW DB2LOTHW DB2LODLK
DF55L DB2QLODRS DB2LODRS CMSD_CASCADE_CDP

Other terms

DB2 MVS OS390 z/OS
RAW, LRAW, VARC, VARCHAR FOR BIT DATA, BITVARCHAR

Reason and Prerequisites

DDIC error

Solution

Note that the inconsistency is not critical as long as you stay with ICLI or z/OS USS as the type of connectivity. However, it has to be resolved before you switch the connectivity to DB2 Connect. This usually happens:
during an upgrade from SAP Release <= 4.6D to SAP Releases >= 6.40during an upgrade from SAP Release <= 4.6D to SAP Release 6.10/6.20 if you are running on DB2 v8.1 and apply the 6.40 downward compatible kernel (6.40 DKK; see SAP note 769918 for details)when migrating a system with SAP Release >= 6.10 to DB2 v8.1. In this case you switch to 6.40 DKK and DB2 Connect (see SAP note 731937).Checking the system
===================

To check the system proceed as follows:
1. If the inconsistency is reported in PREPARE phase DBPREP_CHK ensure that you have *** already *** applied the latest upgrade repairs as described in SAP notes 522711 (6.20) and 663240 (6.40). If this is not the case we recommend that you reset PREPARE (using command R3up reset PREPARE) and start anew after performing the following steps (check and removal of inconsistencies).2. Apply the following transports and support packages:
release note(s) transport/support package
======= ======= =========================
4.0B 162250 SAPK40BOSD
4.5B 162818 SAPK45BOSD
4.6B 184399 SAPK46BOSI
4.6C 184399 SAPK46COSH
4.6D 184399 SAPK46DOSF
6.10 427748,407663 SAPK640OC0,SAPKB61044
6.20 427748,407663 SAPK640OC0,SAPKB62052
6.40 427748,686905 SAPK640OC0,SAPKB64012

The corrections contain:the most recent version of transaction DB2X which will be used to check the consistency of the systema fix to the DDIC which ensures that the system stays consistent in the future
Note (only 6.20): SAPKB62052 ensures that the inconsistency does not re-occur. If you cannot apply this Support Package before migrating to DB2 v8.1, you have to check the system and resolve all inconsistencies (as described below) just before you start the migration to DB2 v8.1. Nevertheless, we recommend that you apply SAPKB62052 as soon as possible after the migration.3. Logon to the SAP system4. Call transaction DB2X
The transaction checks all table fields with respect to the database data type VARCHAR FOR BIT DATA and gives either of the following two replies:a) VARCHAR FOR BIT DATA check completed -> all tables are consistent!
==> Your system is consistent and you are done. No further action needs to be taken!b) Table fields with inconsistent data type found (see SAP Note 848384!):
==> The check found inconsistent tables that need to be converted. The affected tables and columns are listed. To remove the inconsistencies perform the steps described below in section “Resolving an inconsistency”.

Resolving an inconsistency
==========================
1. Import transport SAPK46ROSx (all releases!)
The transport is attached to this note.2. Call transaction DB2_RAWFIX
A list of all inconsistent tables is displayed. If none is found the message ‘No inconsistent table found!’ appears and you are done.3. Test the conversion procedure
Select one small or empty table and choose ‘Fix online’. The conversion should finish with status ‘Done’. Alternatively, it is also possible to schedule the action as a batch job (choose ‘Schedule fix’).
If you encounter problems with the stored procedure call in phase ‘Handle Statistics’, either resolve the problem or switch off the usage of stored procedures by choosing ‘Options’->’No stored procs’. In the latter case the RUNSTATS call has to be performed manually after finishing the conversion.
If the system runs with 6. 40 downward compatible kernel and DB2 v8.1, the buttons ‘Fix online’ and ‘Schedule fix’ are de-activated. In that case, open an OSS message and let SAP’s development support resolve the inconsistencies.4. Convert the remaining tables
If the “test” conversion in the last step was completed successfully, select all other tables and choose ‘Fix online’ (up to 15 tables) or ‘Schedule fix’ and convert these remaining tables.5. Check the system consistency
Once the conversion of all tables has been finished, repeat the check by choosing ‘Repeat complete check’. The result should be ‘No inconsistent table found!’.