DBCS data and what the edit routine receives

The data to be formatted is in the field ECSINPT, and the length of that data, in bytes, is in ECSINLEN.

What you find in ECSINPT depends, to some extent, on where the data originates. More precisely, it depends on whether the column containing that data is a character column or one with a graphic data type.

Data from character columns

If the data to be processed comes from a character column, then the data in ECSINPT is just a copy of the column data. Unlike data from a graphic column, this data can hold single-byte characters and shift characters, as well as DBCS characters. To locate DBCS characters, you must search for the SO and SI characters that bracket the DBCS strings. If there are no SO or SI characters in ECSINPT, the string contains no DBCS data. For example, suppose that ECSINPT contains the following string:

Here, c, d, and e stand for any possible byte, and SO and SI are shift bytes. From the placement of the shift bytes, you can see that every occurrence of c represents a single-byte character, and that every occurrence of de represents a DBCS character.

Single-byte characters can represent Latin letters, Arabic numerals, and special characters such as plus signs and parentheses. For Japanese character sets, they can also be Katakana characters. Some bytes meant to represent lowercase Latin might be displayed as Katakana symbols. You might have to devise edit codes that distinguish between columns containing lowercase English and those containing Katakana.

Data from graphic columns

If the data to be formatted is from a column with a graphic data type, then the text in ECSINPT consists of this data preceded by one shift character and followed by another. Both shift characters are single bytes. For DBCS display devices, shift characters mark the start and end of a string of DBCS characters.

SO denotes the shift character that introduces a DBCS string, and SI denotes the one that marks its end. SO has the value X'0E'. SI has the value X'0F'. The shift characters are included in the data length recorded in ECSINLEN.

Thus, the length appearing in ECSINLEN is always greater by two than the length of the actual data. Because the data is presumably a string of DBCS characters, its length (in bytes) is always an even number.