Message translation
All IMS error messages (for example, DFS555) are sent as either ASCII or EBCDIC. The client application uses the IRM_ID field of the IMS request message (IRM) header to tell IMS Connect which type to send. IMS Connect does not transform messages to Unicode.
For example, if IRM_ID is EBCDIC, the IMS error message (DFSnnnn) is sent as EBCDIC; if IRM_ID is ASCII, the IMS error message (DFSnnnn) is translated from EBCDIC to ASCII.
IRM_ID also identifies the code type of the OTMA header.
- A through Z (uppercase only)
- 0 through 9
- Special characters #, $, @
An IMS host application that supports Unicode must define an 8-byte field in the input message definition to contain the transaction code. If you pad the 8-byte field with a blank, it is sent as an EBCDIC blank.
If the client application sends Unicode data, the output message is not transformed and is treated as Unicode. For RESUME TPIPE calls, the client application must specify in the IRM if the output should be treated as Unicode or not. During message switching, the IMS host application must ensure that the output message is formatted correctly (using a specific Unicode schema or EBCDIC) for its destination.
Input message format sent by the client
The following table contrasts the message structure for input messages sent by the client and defines the valid ASCII, EBCDIC, and UNICODE formats.
EBCDIC IRM | ASCII IRM | If OTMA headers are passed by client | Transaction code | Data |
---|---|---|---|---|
Y | N/A | EBCDIC | EBCDIC | UNICODE |
Y | N/A | EBCDIC | UNICODE | UNICODE |
N/A | Y | ASCII | ASCII | UNICODE |
N/A | Y | ASCII | UNICODE | UNICODE |
Output message format received by the client
The following table defines the valid output message elements when the client sends UNICODE data.
If input message was EBCDIC IRM | If input message was ASCII IRM | RMM | RSM | Output CSM | Output data |
---|---|---|---|---|---|
Y | N/A | EBCDIC | EBCDIC | EBCDIC | UNICODE |
N/A | Y | ASCII | ASCII | ASCII | UNICODE |