[z/OS]

Collecting information for triggering programs problems on z/OS

If you need assistance to resolve a triggering programs 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 problem did you observe on the system?
  • What time did the problem start and has it stopped?
  • Which queue managers, channels, remote queues and transmission queues are involved?
  • What message number and error codes did you receive?
Investigate the following:
  • Search the IBM MQ Support site for known problems. using, for example, any error messages or return codes.
  • For the trigger monitor:
    • Make sure that the trigger monitor is running and monitoring the initiation queue, not the transmission queue.
    • Verify that the user ID used to start the trigger monitor has the authority to access the entire path to the executable code.
  • Verify that your applications are putting their messages to the trigger queue, not the initiation queue.
  • Try to start the trigger program manually using the string specified in the APPLICID property of your process definition. See DEFINE PROCESS for more information.
  • Check for security errors in your External Security Manager, for example, RACF.
  • Check logs for your External Security Manager to see if there is a security failure.

About this task

If you can reproduce the 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

  1. 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. Dumps generated at point of failure.
      See IBM MQ for z/OS dumps.
    3. Dumps taken at the point of failure.
      See Using the z/OS DUMP command.
    4. A LOGREC report
      See A LOGREC report and SYS1.LOGREC information on z/OS.
    5. A full display of the related object definitions:
      • Trigger queue
      • Initiation queue
      • Process
  2. Optionally, generate the following traces while the problem is happening:
    1. Generate a GTF trace.
    2. Generate a MSTR internal trace.
    3. Generate a CHIN trace.
  3. 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.
  4. 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.

  5. 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.