MustGather: Read first for problems encountered with IBM z/OS Debugger

MustGather: Read first table of contents:

---

	Gathering general information
	Gathering problem specific information
	Submitting information to IBM Support

General hints and tips

What is a MustGather document and how does it help me?

---

 

---

 

Gathering general information

General information is information that is needed for any reported problem, and this information includes the following:

• A complete description of the problem, including the following:
  • When did the problem first occur?
  • Is the problem a one time failure or reoccurring?
  • Was software maintenance applied?
  • A test scenario including what the application was doing at the time of the failure and the debugging commands used.
• z/OS Debugger version and maintenance level. Use CALL %VER to obtain your z/OS Debugger version. For additional information, refer to How to determine service level.
• Compiler or assembler version.
• Subsystem (CICS, DB2, IMS, WebSphere Application Server) version, release, and modification. If you do not know the subsystems used in your environment, contact your system administrator.
• Operating system OS/390 or z/OS version, release, and maintenance level if known. This information can be obtained through SMP/E.
• Language Environment version and maintenance level if known. The version is often the same as the operating system version that you are running.
• A valid contact phone number and email address

Gathering problem specific information

Select the problem type or component that best describes your Debugger problem.

 

z/OS Debugger problems

Abend occurring in either z/OS Debugger or your application

Unexpected results

Installation problem

CICS problem

Remote Debug problem

DTSU problem

VTAM or Terminal Interface Manager problem

Performance problem

Out of Storage

IMS Isolation problem

SSL Connection problem

 
Abend occurring in z/OS Debugger or your application

Gather the following documentation for abends occurring during a debug session:

• SYSMDUMP. For information on how to request a dump under Language Environment using TERMTHDACT
• If your environment includes a CICS region, see CICS problem.

 

Unexpected results

Gather the following documentation for unexpected results:

• z/OS Debugger log containing the following:
  1. The command you used,
  2. The output from the command, and
  3. Any error messages you received.

For information on creating a z/OS Debugger log file, refer to the z/OS Debugger for z/OS User's Guide at https://www.ibm.com/support/pages/ibm-debug-zos-library .
 

Installation problem

Gather the following documentation for installation problems:

• SMP/E output from APPLY problems
• JES output from failed job runs including failing IVP runs

 

CICS problem

Gather the following documentation for CICS problems:

• CICS version, release, and maintenance level. Contact your CICS administrator for this information.
• If the problem can be re-created:
  1. Start up JCL for CICS region
  2. JES output for CICS region
  3. Profile creation in DTCN or CADP
  4. Screen captures of entries in DTCN/CADP
  5. Load modules used in re-creating the problem
  6. Steps leading up to the failure
• If the problem cannot be re-created gather the following:
  • A SYSMDUMP that includes CICS trace information. To create a SYSMDUMP that includes CICS trace information, specify the following :
    1. Use CETR to set all domains to ‘1’, except for ‘AP’ and 'EI', which are set to ‘1-2’.
    2. If you are using Remote Debug via TCPIP, set 'SO' to '1-2'
    3. If you encountered a storage problem, for example, a short-on-storage (SOS) error, set the trace component SM to '1-2'
    4. Trace Table Size must be set at a minimum of 10 megabytes.
    5. Use CEMT INQ SYS to verify the dumping parameter is set to SYSDUMP. If it is not, set to SYSDUMP by over typing the current value.
    6. Set up a TRD for the CICS abend code you are seeing. For example, CEMT SET TRD(ASRA) ADD SYSDUMP
  • JES output for CICS region

 

Remote debugger problem

Gather the following documentation for remote debugger problems:

• Version and release of the remote debugger you are using. Provide a screen capture of this information. You can use the About option in the Help pull-down menu to obtain release information.
• TEST RUNTIME string that was used to invoke the debugger.
• The daemon to which the workstation is listening.
• If possible, provide a test case with instructions on how to re-create the problem.
• If a test case cannot be provided, provide an Execution and Program Data Control (EPDC) trace.
  To enable EPDC trace collection on headless code coverage: add the parameter -Iepdcdump=directory_to_store_EPDC_traces when you start headless code coverage.
  You can find the collected EPDC on the indicated directory for Iepdcdump.
• Provide workspace log of the IDE: workspace_directory/.metadata/.log
• For z/OS Debugger Profile issue, collect tracing for it.
  To turn tracing on for z/OS Debugger Profiles, go to preference page for tracing: Menu > Window > Preferences, expand General, select item Tracing.
  On Tracing page, check on Enable tracing.
  On the table of Tracing Options, expand the item z/OS Debugger Profiles.
  Set value to true for selected z/OS Debugger Profiles’ tracing option.
• WTO messages issued by z/OS Debugger for TCPIP errors. These messages provide useful information, such as error type and TCPIP socket function code. You can collect these messages from the job output or console log.
• If your connection was lost, provide a SYSMDUMP. For information on how to request a dump, refer to II10573: Instructions on how to request a SYSMDUMP when running under Language Environment.

 
DTSU problem

Gather the following documentation for DTSU problems:

• EQASTART trace:
  1. In the EQASTART file there is this statement: xrc = trace "O"). Replace the "O" with "?R" as follows: xrc trace "?R") And save this update.
  2. Restart EQASTART. When the trace starts, you see the current executable statement displayed in the foreground.
  3. Press Enter to advance to the next instruction.
• Perform a screen capture of the following DTSU dialog panels. Enter the panel id command in the ISPF command prompt to display the ISPF panel IDs.
  • EQAPFORS - Main DTSU panel
  • EQAPFPRM - Display this panel by entering forward-slash in the "Enter / to modify parameters" field.
  • ISREDDE2 - Generated JCL created by pressing F10-Submit in the EQAPFORS panel
• Setup files
  • hlq.SEQATLIB: EQAZDFLT. EQAZDSYS, EQAZDUSR
  • hlq.EQASTART: EQASTART
  • DTSU
• Use TSO ISRDDN output to show data set concatenations. For information about ISRDDN, refer to the ISPF User's Guide at: http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/ISPZUG50/CCONTENTS?SHELF=ispzpm50&DN=SC34-4822-05&DT=20060621022939

 

VTAM  or Terminal Interface Manager problem

Gather the following documentation for VTAM and Terminal Interface Manager problems:

• JCL output
• VTAMLST member containing the definitions for the EQAnnn minor node
• Terminal LU definitions (EQAWTRML)
• TCPIP configuration file information for VTAM port definitions
• EQAYSESSM job output (for Terminal Interface Manager only)
• If you see EQA1998S messages, capture a dump of the debug job that issues the messages, as well as the Terminal Interface Manager address space, by using the following SLIP command".
   SLIP SET,ACTION=SVCD,
     MSGID=EQA1998S,
    SDATA=(ALLNUC,NUC,PSA,SQA,lsqa,CSA,GRSQ,LPA,TRT,SUM,RGN),
    JOBNAME=xxxxxxxx,
    MATCHLIM=nn,
   END
   

  If your EQA1998S messages are preceded by a EQA9932S, ensure that you are logged on to Terminal Interface Manager.

 
Performance problem

Gather the following documentation for performance problems:

• Test case with instructions on how to re-create the problem. Include all necessary files, such as the load module, DLLs run with the load module, etc. (LMODS, SIDEFILES/LISTINGS, DLLs, SOURCE). For CICS test cases, include any maps needed to run the application.
• Output of Q SET command issued in an active z/OS Debugger session by the same user experiencing the performance problem
• Output from any performance monitoring tools such as Application Performance Analyzer for z/OS.
• SYSMDUMP. For information on how to request a dump, refer to http://www.ibm.com/servers/eserver/zseries/zos/le/assist/support/10573r7.html.
• If running under CICS, do ONE of the following:
  • Include a SYSMDUMP that includes CICS trace information. See CICS problem.

OR

• • Create a CICS auxiliary trace. Specify the following CICS Startup parameters:
    1. Use CETR to set all domains to ‘1’, except for ‘AP’ and "EI" which are set to ‘1-2’. Trace Table Size must be set at a minimum of 10 megabytes and Auxiliary Trace Status set to started. FTP the unformatted trace that is created.
    • For additional information about creating a CICS auxiliary trace, refer to the CICS Problem Determination Guide at http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/DFHS1B00.

 
Out of storage

Gather the following documentation for storage problems:

• Test case with instructions on how to re-create the problem. Include all necessary files, such as the load module, listing, source, EQALANGX, DLLs run with the load module, etc. (LMODS, SIDEFILES/LISTINGS, DLLs, SOURCE). For CICS test cases, include any maps needed to run the application.
• When running under Language Environment , gather an Language Environment storage report if possible. Setting Language Environment runtime option RPTS(ON) creates a storage report when the program runs to completion. If the program only runs to completion without z/OS Debugger, create the report without z/OS Debugger.
• Create a SYSMDUMP of the out of storage error. For information on how to request a dump under Language Environment, refer to http://www.ibm.com/servers/eserver/zseries/zos/le/assist/support/10573r7.html.
• If running under CICS, do ONE of the following:
  • • Include a SYSMDUMP that includes CICS trace information. See CICS problem.
  • OR
    • Create a CICS auxiliary trace. Specify the following CICS Startup parameters:
    
    
    • Use CETR to set all domains to ‘1’, except for ‘AP’ and 'EI' which are set to ‘1-2’. Trace Table Size must be set at a minimum of 10 megabytes and Auxiliary Trace Status set to started. Ftp the unformatted trace that is created.
    
    For additional information about creating a CICS auxiliary trace, refer to the CICS Problem Determination Guide at http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/DFHS1B00.

 
Debugger IMS ISO 

1. If the private message region is not starting check if region servicing the class of the transaction is active before you start an ISO region 
2. Check which classes where reserved for the debugger, the output of /DIS TRAN EQA* output needs to match the reserved classes

 
SSL Connection Problem

Gather the following documentation for SSL connection problems:

For SSL GUI host:

• Output from netstat -f
• Check that: TTLS: YES

• Make the following change in the TTLS rule
  • Trace 30
• Rerun scenario and send us the communication server logs
  • daemon.debug /syslog/daemon.log
  • daemon.info /syslog/daemon.log

If there is nothing - here are the steps to find the location :

• /d omvs,a=all
• f syslogd pref -> location conf file
• Browse conf file to get the locations

 


Submitting information to IBM Support

After a case is opened, you can submit diagnostic MustGather data to IBM using one of the following methods:

FTP diagnostic data to IBM
If FTP is not possible, email diagnostic data to techsupport@ecurep.ibm.com. You must add the case number in the subject line of your email. Click here for more details.

Always update your case to indicate that data has been sent. You can update your case, or open a new case, in one of two ways:

• Online: Go to the Submit and track problems page on the IBM Software Support site or SR Tool to open a Service Request (SR). Enter your information into the appropriate problem submission tool.
• By phone: Call 1-800-IBMSERV (1-800-426-7378) in the United States or, from other countries, go to the contacts page of the IBM Software Support Handbook on the Web (techsupport.services.ibm.com/guides/contacts.html) and click the name of your geographic region.

 
General hints and tips

• Search for known problems on https://www.ibm.com/support/pages/known-issues-and-limitations-ibm-zos-debugger
• Search the z/OS Debugger for z/OS documentation in https://www.ibm.com/docs/en/debug-for-zos/latest
• Search Lookat Messages for detailed message information.
• Obtain the latest z/OS Debugger maintenance.
• Obtain the latest Compiler and Language Environment maintenance for z/OS Debugger.
• Review Preventive Service Planning buckets if you are installing or migrating z/OS Debugger.
• Learn about the Electronic Service Request (ESR) tool for submitting problems electronically.

 

What is a MustGather document and how does it help me?

MustGather documents aid in problem determination and save time resolving Problem Management Records (PMRs). These documents are located on the product support sites and contain specific instructions about what documentation to gather for specific problems. You can find MustGather documents by searching on the word MustGather on the eSupport Web page:

http://www.ibm.com/software/awdtools/deployment/support/

Collecting MustGather data early, even before opening the PMR, helps IBM® Support quickly determine if:

1. Symptoms match known problems (rediscovery).


2. There is a non-defect problem that can be identified and resolved.


3. There is a defect that identifies a workaround to reduce severity.


4. Locating root cause can speed development of a code fix.

   

Receive weekly Support email

Sign up for My Notifications to receive a customized weekly email from IBM support. Learn about announcements and important technical support information. Top of page