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.
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).
| Item | Detail |
|---|---|
| SQL form | CHAR(n) or CHARACTER(n) |
| Length n | 1–255 |
| Storage | n bytes (for SBCS CHAR) |
| Length behavior | Fixed; short values padded |
| Typical use | Codes, flags, short fixed attributes |
1234567CREATE 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) );
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.
123456INSERT 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
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.
12345Rule 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
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.
Character literals use string delimiters (typically apostrophes in COBOL environments): 'CA', 'R'. Host variables for CHAR columns are fixed alphanumeric fields:
1234567891001 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.
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.
1. What is the allowed length range for CHAR(n) in Db2 for z/OS?
2. CHAR columns are best described as:
3. A common COBOL mapping for CHAR(10) is:
4. When is CHAR often preferred over VARCHAR?
5. CHAR(5) storing ABC is typically stored as: