No longer in GT.M since: undefined
ENCODING, M or W-1252 code designation for character set encoding, might return unexpected results when ""UTF-8""=$ZCHSET
Compile Time Warning: When in UTF-8 mode (variable length encoding) and code contains $ZCONVERT() with the second or third argument specified as literal M or W-1252 (single byte encodings) the compiler warns there may be encoding issues.
Action: If the first argument (string to convert) is always pure ASCII, the conversion is unnecessary, so consider removing it. With a second argument of M or W-1252 unless the first argument has an external source or has been generated by $ZCHAR() it likely already has UTF-8 encoding, and an additional conversion won't yield desired results. With a third argument of M or W-1252 the result may contain characters unintended for, or incompatible (could generate BADCHAR errors) with, the running UTF-8 character set and therefore require handling with $Z* byte-oriented functions. In other words, the $ZCONVERT() second and third arguments specify how the function operates not whether its input or output are appropriate in the context of the specified operation so consider the use case carefully. Note that when the second and/or third arguments are non-literal expressions, the compiler cannot determine whether an ENCODING warning might be appropriate. Also note that the UTF-16 encodings supported by the function have compatibility issues but because GT.M does not natively support those encodings the issues are more overt and do not generate ENCODING warnings.
