For KanjiEBCDIC, the problem occurs when a single-byte character is placed between two sequences of multibyte characters.
For example, consider the following SELECT statement.
SELECT '平成1年';
平成1年, where the 1 is a single-byte character, is translated internally to UCS2.
5E | 73 | 62 | 10 | 00 | 31 | 5E | 74 |
平 | 成 | 1 | 年 |
Because this is four characters, the expected-defaults exports at most ten bytes, but the representation of 平成1年 in KanjiEBCDIC requires eleven bytes.
0E | 45 | 8D | 45 | BA | 0F | 31 | 0E | 45 | 60 | 0F |
< | 平 | 成 | > | 1 | < | 年 | > |
Therefore the output must be truncated to ten bytes.
Truncation occurs at a character boundary, so the output is truncated to 平成1, which requires seven bytes.
If this were a fixed width field, these seven bytes would be padded with SPACE characters to produce ten bytes. Because the field is not fixed width, only seven bytes are output (excluding the length information which is always included in variable width data).
0E | 45 | 8D | 45 | BA | 0F | 31 |
< | 平 | 成 | > | 1 |