Variant characters

Variant characters are characters that correspond to different code points across a given set of code pages. For example, the character # is variant. It corresponds to code point X'7B' in CCSIDs 37, 273, 500, and 1047. However, this character corresponds to code point X'4A' in CCSID 277.

An invariant character is a character that corresponds to the same code point regardless of CCSID.

Ideally, you should use invariant characters when possible. However, if you do use variant characters, ensure that Db2 uses the correct CCSID to interpret them.

For example, consider the following national characters: #, @, and $. Although you can use these characters in object identifiers, you should be aware that they are all variant characters. The following table shows the corresponding hexadecimal code point values for these characters in several different code pages.

Table 1. Variant characters that you can use in identifiers
Character Corresponding hexadecimal value by code page
CCSID 37 CCSID 500 CCSID 1047 CCSID 277 CCSID 273
# X'7B' X'7B' X'7B' X'4A' X'7B'
@ X'7C' X'7C' X'7C' X'80' X'B5'
$ X'5B' X'5B' X'5B' X'67' X'5B'

You need to be careful when you use these characters in identifiers, such as package names, table space names, index space names, and field procedure names. All of these objects have corresponding data sets, DBRMs, or load modules that are defined in z/OS® with corresponding names. Problems can occur if you use a different CCSID when the object is created than when it is referenced. In this case, the corresponding data sets, DBRMs, or load modules might not be found in z/OS because of the variant characters in the names.

Another example of a variant character that might cause problems is the double quotation mark ("). In the Turkish code page CCSID 1026 this character corresponds to code point X'FC'. However, this code point is not the same in other EBCDIC code pages.

Also avoid using variant characters in SQL statements. For example, suppose that you want to use an operator to mean "not equal." Coding <> is the best choice, because these characters are invariant across most EBCDIC CCSIDs. However, depending on the situation, Db2 might tolerate other operators for "not equal" such as !=, or ¬=. For details about the conditions that need to be satisfied for Db2 to tolerate those operators, see Basic predicate. Even if these conditions are satisfied, the exclamation point character (!) and the not character (¬) are variant and can therefore cause other problems. For example, these characters might not be displayed correctly on a client. Also, you might have conversion issues if the SQL statement is copied from the catalog or read by another system.

To prevent such problems with variant characters, use the following recommendations.

Best practices:
  • Use invariant characters in identifiers and SQL statements.
  • When you name Db2 objects, use only those characters that you can type on your keyboard. Do not use hexadecimal values in object names. Doing so can unnecessarily complicate your applications and queries.
  • Use CONCAT instead of || when you need to concatenate values.
  • Use <> to mean "not equal" instead of != or ¬=.
  • Do not use variant hexadecimal code points from another code page. Doing so might cause conversion errors.