Db2 CHAR Data Type

CHAR (also written CHARACTER) is Db2 for z/OS’s fixed-length character string type. State codes, status flags, product type codes, and other short, stable attributes often live in CHAR columns. This page explains how CHAR works, how length and padding behave, how it compares to VARCHAR, and how COBOL programs map CHAR with PIC X.

Db2 data types
Progress0 of 0 lessons

What CHAR is

A CHAR(n) column stores a character string whose length attribute is exactly n. For Db2 for z/OS, n must be in the range 1–255. The byte count for a single-byte character CHAR(n) value is n. Character data is interpreted according to the column’s CCSID / encoding attributes (EBCDIC, Unicode, and related topics appear in later lessons).

CHAR at a glance
ItemDetail
SQL formCHAR(n) or CHARACTER(n)
Length n1–255
Storagen bytes (for SBCS CHAR)
Length behaviorFixed; short values padded
Typical useCodes, flags, short fixed attributes
sql
1
2
3
4
5
6
7
CREATE TABLE CUSTOMER ( CUST_ID CHAR(8) NOT NULL, CUST_TYPE CHAR(1) NOT NULL, STATE_CD CHAR(2), CUST_NAME VARCHAR(40) NOT NULL, PRIMARY KEY (CUST_ID) );

Fixed length and padding

If you assign a shorter string to CHAR(n), Db2 pads it to length n—commonly with blank characters for character data. That means CHAR(5) holding 'AB' is stored as five characters, not two. Applications that concatenate CHAR columns or compare them to VARCHAR values must understand padding or they will see unexpected spaces.

sql
1
2
3
4
5
6
INSERT INTO CUSTOMER (CUST_ID, CUST_TYPE, STATE_CD, CUST_NAME) VALUES ('C1000001', 'R', 'CA', 'Riverdale Retail'); -- STATE_CD CHAR(2) stores 'CA' -- CUST_TYPE CHAR(1) stores 'R' -- Assigning 'A' to CHAR(2) pads to length 2

Comparisons and blanks

SQL string comparison often blank-pads the shorter operand to the longer length for character comparisons. That helps CHAR and short literals compare naturally, but it can hide trailing-blank differences you care about in other contexts. When blanks are semantically meaningful, be explicit—RTRIM, predicates on VARCHAR, or application-side trimming—according to your rules.

When to use CHAR

  • Codes with a fixed width (country, state, currency, status)
  • Flags and single-character indicators
  • Short IDs that are always the same length in the business model
  • Columns that participate heavily in indexes where fixed width is predictable

When VARCHAR is a better fit

  • Names, addresses, comments, and other variable-length text
  • Strings that may exceed 255 bytes
  • Data where padding blanks would waste space or confuse interfaces
text
1
2
3
4
5
Rule of thumb: Always length 1–2 and code-like? -> CHAR Length varies a lot or > 255? -> VARCHAR (or CLOB for huge text) Raw bytes, not characters? -> BINARY / FOR BIT DATA forms

Character data vs FOR BIT DATA

Ordinary CHAR holds character strings under a CCSID. CHAR FOR BIT DATA treats the bytes more like a binary string without SBCS character semantics—useful for some opaque byte codes, but easy to misuse if you actually needed readable text. Beginners should default to plain CHAR for business codes and learn bit-data subtypes when a design explicitly needs them.

Literals and host variables

Character literals use string delimiters (typically apostrophes in COBOL environments): 'CA', 'R'. Host variables for CHAR columns are fixed alphanumeric fields:

cobol
1
2
3
4
5
6
7
8
9
10
01 WS-CUST-ID PIC X(8). 01 WS-STATE-CD PIC X(2). 01 WS-CUST-NAME PIC X(40). EXEC SQL SELECT STATE_CD, CUST_NAME INTO :WS-STATE-CD, :WS-CUST-NAME FROM CUSTOMER WHERE CUST_ID = :WS-CUST-ID END-EXEC.
  • Match PIC X length to CHAR(n)
  • Moving CHAR into a longer PIC X field leaves trailing content—initialize host fields
  • Nullable CHAR columns need indicator variables; distinguish null from blank strings
  • Encoding mismatches (wrong CCSID assumptions) corrupt characters even when lengths match

Design tips

  • Document whether codes are case-sensitive and whether blanks are allowed
  • Prefer CHAR for truly fixed codes; do not use CHAR(255) as a lazy VARCHAR
  • Avoid storing numbers in CHAR unless they are identifiers with leading zeros (then document why)
  • For natural keys like CUST_ID CHAR(8), enforce format in application and/or CHECK constraints where appropriate

Explain It Like I'm Five

CHAR is a label sticker that is always the same size. If your name is short, the sticker still takes the full space and fills the rest with blank padding. VARCHAR is a stretchy sticker that shrinks or grows with the letters (within limits). Tiny codes like state abbreviations love fixed stickers. Long stories love stretchy ones.

Exercises

  1. What are the minimum and maximum values of n in CHAR(n)?
  2. Design columns for: country code (2 letters), customer free-form name, and a Y/N active flag—choose CHAR or VARCHAR for each and say why.
  3. Explain what happens when you INSERT 'NY' into a CHAR(5) column.
  4. Write a COBOL PIC clause for CHAR(8) and CHAR(1) host variables.
  5. Give one reason CHAR(100) for a comments field is usually a poor design choice.

Quiz

Test Your Knowledge

1. What is the allowed length range for CHAR(n) in Db2 for z/OS?

  • 0–100 only
  • 1–255
  • 1–32704
  • Unlimited

2. CHAR columns are best described as:

  • Variable-length strings with a 2-byte length prefix
  • Fixed-length character strings padded to the defined length
  • Only binary LOBs
  • Only Unicode graphic data

3. A common COBOL mapping for CHAR(10) is:

  • PIC 9(10) COMP-3
  • PIC X(10)
  • PIC S9(10) COMP
  • USAGE POINTER

4. When is CHAR often preferred over VARCHAR?

  • For multi-megabyte documents
  • For short, stable codes that are almost always the full length (state codes, flags)
  • Never—VARCHAR is always better
  • Only for DECFLOAT data

5. CHAR(5) storing ABC is typically stored as:

  • ABC with length 3 only
  • ABC padded with blanks to five characters
  • A BIGINT
  • Compressed always to one byte