[z/OS]

Collecting information for Java and JMS application problems on z/OS

If you need assistance to resolve a JMS or Java 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 JMS or Java problem did you observe on the system?
  • What time did the problem start and when did it stop?
  • Were any Java exceptions reported, and did they include a Java call stack?
  • Which queue managers, queues and topics does the JMS or Java application use?

Search the IBM MQ Support site for known problems using, for example, any error messages or return codes.

The majority of IBM MQ for z/OS Java failures are caused by setup or configuration problems. You must configure the path, classpath, and environment variables correctly. See:

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.
  2. Optionally, generate the following while the problem is happening:
    1. Generate a GTF trace
    2. Generate a MSTR internal trace
    3. Generate a CHIN trace
    4. Tracing IBM MQ classes for JMS applications
    5. Tracing IBM MQ classes for Java applications
    6. Enabling JMS Trace for WebSphere Application Server
  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. For other platforms, see Operating system version and maintenance level.
  4. For standalone applications, record the version of the IBM MQ classes for Java or IBM MQ classes for JMS that are being used.
    Finding the build level for the classes on the current classpath
    Issue the following command: 
    java com.ibm.mq.MQJavaLevel
    or 
    java com.ibm.mq.jms.MQJMSLevel
    Finding the build level for a jar files in a specific directory:
    Change to the directory containing the jars, and issue the following command:
    java -cp com.ibm.mq.jar com.ibm.mq.MQJavaLevel
    or 
    java -cp com.ibm.mqjms.jar:com.ibm.mq.jar com.ibm.mq.jms.MQJMSLevel
    If you receive java.lang.NoClassDefFoundError for MQJavaLevel or MQJMSLevel, you need provide a path to the class. You can use one of the following methods:
    1. Specify the CLASSPATH in the command:
      java -cp path/com.ibm.mq.jar com.ibm.mq.MQJavaLevel
      where path is the directory path which contains the jar file of interest.
      For example:
      java -cp ./com.ibm.mq.jar com.ibm.mq.MQJavaLevel
      gives version information for the com.ibm.mq.jar file in the current directory, or 
      java -cp /usr/lpp/mqm/V9R3M0/java/lib/com.ibm.mq.jar com.ibm.mq.MQJavaLevel
      gives version information for the file /usr/lpp/mqm/V9R3M0/java/lib/com.ibm.mq.jar.
      Note: java -cp /usr/lpp/mqm/V9R3M0/java/lib/com.ibm.mq.jar com.ibm.mq.MQJavaLevel must be on one line.
    2. Set up the CLASSPATH and LIBPATH environment variables.

      See Setting environment variables for IBM MQ classes for JMS/Jakarta Messaging and Configuring the Java Native Interface (JNI) libraries to match the settings used by the application or WebSphere Application Server.

      The "env" command in OMVS will show you what your current settings are.

      If you need to set the variables for your OMVS session, the following export commands are an example of what to issue from the OMVS command line or add to your .profile:
      export LIBPATH=/usr/lpp/mqm/V9R3M0/java/lib:$LIBPATH
export CLASSPATH=/usr/lpp/mqm/V9R3M0/java/lib/com.ibm.mq.jar:$CLASSPATH
export CLASSPATH=/usr/lpp/mqm/V9R3M0/java/lib/com.ibm.mqjms.jar:$CLASSPATH
      Notes:
      • /usr/lpp is an install directory that might be different for your environment
      • These variables are the minimum needed to display the levels
      • The run-time CLASSPATH contains other libraries.
  5. 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.

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