Diagnostic information produced on IBM MQ for z/OS

Use this topic to investigate some of the diagnostic information produced by z/OS that can be useful in problem determination and understand how to investigate error messages, dumps, console logs, job output, symptom strings, and queue output.

IBM MQ for z/OS functional recovery routines use z/OS services to provide diagnostic information to help you in problem determination.

The following z/OS services provide diagnostic information:

SVC dumps

The IBM MQ abend completion code X'5C6' uses the z/OS SDUMP service to create SVC dumps. The content and storage areas associated with these dumps vary, depending on the specific error and the state of the queue manager at the time the error occurred.

SYS1.LOGREC

Entries are requested in the SYS1.LOGREC data set at the time of the error using the z/OS SETRP service. The following information is also recorded in SYS1.LOGREC:

Subsystem abnormal terminations
Secondary abends occurring in a recovery routine
Requests from the recovery termination manager

Variable recording area (VRA) data

Data entries are added to the VRA of the SDWA by using a z/OS VRA defined key. VRA data includes a series of diagnostic data entries common to all IBM MQ for z/OS abend completion codes. Additional information is provided during initial error processing by the invoking component recovery routine, or by the recovery termination manager.

IBM MQ for z/OS provides unique messages that, together with the output of dumps, are aimed at providing sufficient data to allow diagnosis of the problem without having to try to reproduce it. This is known as first failure data capture.

Error messages

IBM MQ produces an error message when a problem is detected. IBM MQ diagnostic messages begin with the prefix CSQ. Each error message generated by IBM MQ is unique; that is, it is generated for one and only one error. Information about the error can be found in IBM MQ for z/OS messages, completion, and reason codes.

The first three characters of the names of IBM MQ modules are also usually CSQ. The exceptions to this are modules for C++ (IMQ), and the header files (CMQ). The fourth character uniquely identifies the component. These identifiers are listed in IBM MQ component and resource manager identifiers. Characters five through eight are unique within the group identified by the first four characters.

Make sure that we have some documentation on application messages and codes for programs that were written at your installation, as well as viewing IBM MQ for z/OS messages, completion, and reason codes

There might be some instances when no message is produced, or, if one is produced, it cannot be communicated. In these circumstances, you might have to analyze a dump to isolate the error to a particular module. For more information about the use of dumps, see IBM MQ for z/OS dumps.

Dumps

Dumps are an important source of detailed information about problems. Whether they are as the result of an abend or a user request, they allow you to see a snapshot of what was happening at the moment the dump was taken. IBM MQ for z/OS dumps contains guidance about using dumps to locate problems in the IBM MQ system. However, because they only provide a snapshot, you might need to use them with other sources of information that cover a longer period of time, such as logs.

Snap dumps are also produced for specific types of error in handling MQI calls. The dumps are written to the CSQSNAP DD.

Console logs and job output

We can copy console logs into a permanent data set, or print them as required. If we are only interested in specific events, we can select which parts of the console log to print.

Job output includes output produced from running the job, as well as that from the console. We can copy this output into permanent data sets, or print it as required. We might need to collect output for all associated jobs, for example CICS, IMS, and IBM MQ.

Symptom strings

Symptom strings display important diagnostic information in a structured format. When a symptom string is produced, it is available in one or more of the following places:

On the z/OS system console
In SYS1.LOGREC
In any dump taken

Figure 1 shows an example of a symptom string.

Figure 1. Sample symptom string

PIDS/ 5655R3600 RIDS/CSQMAIN1 AB/S6C6 PRCS/0E30003

The symptom string provides a number of keywords used to search the IBM software support database. If we have access to one of the optional search tools, we can search the database yourself. If you report a problem to the IBM support center, we are often asked to quote the symptom string. (For more information about searching the IBM software support database, See Searching the IBM database for similar problems, and solutions.)

Although the symptom string is designed to provide keywords for searching the database, it can also give you a lot of information about what was happening at the time the error occurred, and it might suggest an obvious cause or a promising area to start your investigation. See Building a keyword string for more information about keywords.

Queue information

We can display information about the status of queues by using the operations and control panels. Alternatively we can enter the DISPLAY QUEUE and DISPLAY QSTATUS commands from the z/OS console.