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
SIcharacters that bracket the DBCS strings. If there are no
SIcharacters in ECSINPT, the string contains no DBCS data. For example, suppose that ECSINPT contains the following string:
e stand for any possible byte, and
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
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.
the shift character that introduces a DBCS string, and
the one that marks its end.
SO has the value X'0E'.
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.