In this example, two OpenEdge clients use ISO8859–1 for their internal code page. Client1 saves a UTF–8 encoded XML document in a MEMPTR variable (calling the X–DOC:SAVE() ABL method) and then uses the ABL GET–STRING statement to extract the text from the MEMPTR and pass it into the XMLMessage. (This is a deliberate error.) UTF–8 (Unicode Transformation Format) is an 8-bit encoding form that serializes a Unicode scalar value as a sequence of one to four bytes.

An OpenEdge client cannot mix code pages. The text it sets in the XMLMessage must be encoded in the same code page as the client's internal code page. In general, a MEMPTR variable must be used carefully, since it can have any data in it. The ABL programmer must be sure that it contains only NULL free text (no embedded NULL bytes), encoded with the same code page as the internal code page, before loading it into an XMLMessage.

In this example, if the OpenEdge client cannot be started up with –cpinternal UTF–8, but still wants to use ABL–JMS to pass that UTF–8 document, it can use a BytesMessage or bytes elements in a StreamMessage. When sent as bytes, the XML data will get to the receiver uninterpreted and unconverted. The ABL receiver can then set the data in a MEMPTR variable and load the parser.

A second option is to convert the text (and the document's header) to ISO8859–1 using the CODEPAGE–CONVERT ABL function. However, if -cpinternal represents all character, the conversion is automatic if you use LONGCHAR or CHAR. If -cpinternal represents all characters, the conversion is also automatic when you use the new built-in XML routines (SAX-WRITER or setX-Document). When you use the new built-in XML routines, you can create, send, and receive UTF-8 XML documents.

If the ABL receiver of an XMLMessage is unsure about the XML header encoding declaration, it must check it and perhaps modify it to match its internal code page before loading the parser.