Collecting information for data conversion problems on z/OS

If you need assistance to resolve a data conversion problem on IBM® MQ for z/OS®, you might need to collect troubleshooting information to include with your support case to help find a solution to the problem.

Before you begin

Before you start this task, answer the following questions about the problem:

What data conversion problem did you observe on the system?
What time did the data conversion problem start and when did it stop?
Which queue managers, channels, remote queues and transmission queues are involved?

Investigate the following:

An IBM MQ message consists of two parts, the control information in a message descriptor and the application data.
Application data is converted using one of the following methods:
- In an application program when the MQGMO_CONVERT option is specified on an MQGET call.
- In the channel program by specifying CONVERT(YES) keyword on the sender or server channel.
The Format field in the MQMD structure associated with the message must contain a valid format:
- MQFMT_NONE is the initial setting and data conversion does not occur with this setting.
- The built in format (MQFMT_STRING) should be used if the message is string data. IBM MQ data conversion programs convert the data.
- If your message contains numeric data, then you need to have your own format. You also need to write your own exit program to do the data conversion.
- The built in format (MQFMT_CICS) can be used with CICS® messages, however messages in that format can only be converted on IBM MQ on host systems. When sending messages to a different platform you should configure the sender channel process to do the data conversion. See RC 2110 (MQRC_FORMAT_ERROR) for more information.
Conversion of EBCDIC newline characters
If you need to ensure that the data you send from an EBCDIC platform to an ASCII one is identical to the data you receive back again, you must control the conversion of EBCDIC newline characters. This can be done using a platform-dependent switch that forces IBM MQ to use the unmodified conversion tables but you must be aware of the inconsistent behavior that can result.

The problem arises because the EBCDIC newline character is not converted consistently across platforms or conversion tables. As a result, if the data is displayed on an ASCII platform, the formatting can be incorrect. This makes it difficult, for example, to administer an iSeries system remotely from an ASCII platform using RUNMQSC.

For further information about converting EBCDIC-format data to ASCII format, see ConvEBCDICNewline.

About this task

If you can reproduce the data conversion problem or the problem is happening right now, you can generate data to provide more information about the problem.

After collecting the troubleshooting information, you can send it to IBM.

Procedure

Collect the following required information:
1. Job logs
  You require the Syslog, MSTR job log, and CHIN job log.
  The job logs are named xxxxMSTR and xxxxCHIN, where xxxx is the IBM MQ subsystem identifier (SSID).See Creating a print data set containing the JES2 joblog for the IBM MQ for z/OS jobs.
2. A LOGREC report
  See A LOGREC report and SYS1.LOGREC information on z/OS.
3. Gather the following information for the Sending and Receiving queue manager:
  Sending queue manager
```
Queue Manager CCSID:
Putting application setting for MQMD CCSID:
Putting application setting for MQMD Format:
Use CSQ4BCG1 to capture the message on the transmission queue:
What is the character and its Hex representation and offset within the message:
```
  Receiving queue manager
```
Queue Manager CCSID:
Getting Application Setting for MQMD CCSID:
Use CSQ4BCG1 to capture the message on the destination/local queue:
What is the character and its Hex representation and offset within the message:
```
Optionally, generate the following traces while the problem is happening:
Collect the IBM MQ data.
1. Record the version and release number of IBM MQ for z/OS and any other related product.
  See message CSQY000I in the MSTR job log for IBM MQ for z/OS
2. Record the operating system version and maintenance level of your system.
  For the z/OS operating system, find the version in the output of /D IPLINFO in SDSF.
Use the AMATERSE utility before uploading to ECUREP, and ensure you specify the case number with which the data is associated.

For more information, see Using AMATERSE in the z/OS Communications Server: IP Diagnosis Guide.
Send the information that you have collected to IBM.

A good description of the problem and the data is the most important information you can provide to IBM. Do not send data without providing a description!

For FTP and email instructions, see Exchanging information with IBM Software Support.

To open or update a case, go to the IBM My Support site.
Note: Always update your case to indicate that data was sent.

If you need to speak with IBM Software Support, contact your country representative. If you need to speak with IBM Support in the US, you can call 1-800-IBM-SERV.