String processing statements, whose arguments were all interpreted as fields of type C until now, are now divided into statements with character arguments and those with byte arguments.
String processing statements
CLEAR ... WITH
CONVERT TEXT ... INTO SORTABLE CODE
TRANSLATE ... TO UPPER/LOWER CASE
TRANSLATE ... USING
The arguments of these instructions must be single fields of type C, N, D, T or STRING or structures of character-type only. There is a syntax or runtime error if arguments of a different type are passed. A subset of this function is provided with the additionIN BYTE MODE for processing byte strings – that is, operands of type X or XSTRING. A statement such as CONCATENATE a x b INTO c is thus no longer possible when a,b, and c are all character-type, but x is of type X.
TRANSLATE ... CODEPAGE ...
TRANSLATE ... NUMBER FORMAT ...
The above statements are not allowed in Unicode programs. Instead, you can use the new conversion classes, which are described in more detail inConverting Data.
Comparison operators for string processing
As with the string processing statements, these operators need single fields of type C, N, D, T or STRING as arguments and again structures of character-type only are allowed. Special compare operators defined with the prefix BYTE- are provided for byte strings.
Functions for string processing
Function STRLEN only works with character-type fields and returns the length in characters. The new function XSTRLEN finds the length of byte strings.
Until now, function CHARLEN returned the value1 for a text field beginning with a single byte character under an NUS. The value 2 is returned for text fields beginning with a double byte character. Under a US, CHARLEN returns the value 1 if text begins with a single Unicode character. If text begins with a Unicode double character from the surrogate area, the value 2 is returned.
Function NUMOFCHAR returns the number of characters in a string or a character-type field. In single byte code pages, the function behaves like STRLEN. In multi-byte code pages, characters filling more than 1 byte are nevertheless considered to have length 1.
Output in fields and lists
In WRITE ...TO, any flat data types that were handled like C fields were allowed as the target field. A UP now requires that the target field be of character-type in a WRITE ... TO ... statement. The line type of the table must be of character-type for the table variant WRITE ... TO itab INDEX idx. The offset and length are counted in characters.
Until now, any flat structures could be output with WRITE. If the source field is a flat structure in a WRITE, it must have character-type only, in a UP. This affects the following statements:
WRITE f TO g[+off][(len)].
WRITE (name) TO g.
WRITE f TO itab[+off][(len)] INDEX idx.
WRITE (name) TO itab[+off][(len)] INDEX idx.
Use the categories used in the Dictionary when using these types withStructure Enhancements.