Troubleshooting: compiled language debugger does not start
Describes some unexpected behaviors you might observe, possible reasons for the unexpected behavior, and how to find and fix possible mistakes.
About this task
The suggestions described in this topic can help you determine why the compiled language debugger does not start. Before reviewing the list, obtain the TCP/IP address of your workstation by doing the following steps:
- Open the Debug perspective.
- Ensure that the Debug Daemon is listening
- From the Debug Daemon pull-down menu, select Get workstation ip.... The window displays a list of IP addresses. If you see more than one IP address, you can configure more than one network device or adapter for your workstation. Make note of the IP address for the active adapter.
- Close the window.
Before you review any of these suggestions, verify that the
debug daemon on your workstation is listening by locating the listener
icon on the right side of the Debug view. If the listener icon is
green (
), the debug daemon is listening.
If the listener icon is red (
), the debug daemon is not listening. Click on
the icon to make the debug daemon listen.
| Observed behavior | Explanation | Solution |
|---|---|---|
| You were able to start a remote debug session with an earlier version of the debugger (for example, WebSphere® Developer Debugger for System z®), but you can not start one with your current debugger. | The default port number changed beginning with the release of WebSphere Developer for System z. | If you specified the VADTCPIP& suboption of the TEST runtime option, change it to TCPIP& and specify the new default port number, 8001. If you specified the TCPIP& suboption of the TEST runtime option, change the default port number to 8001. |
| You start your program on the host, but it fails (displays error messages), you see no activity on your 3270 terminal (commonly referred to as "hang"), or you see no activity on the debugger. | Your firewall might be preventing communication between the host and the debugger. | If you are using a firewall, you can use DBMDT instead of TCPIP&. Otherwise, review the instructions for your firewall software on how to give the following programs permission to communicate. |
| You start the debugger and the daemon does not listen (does not switch to green). You click on listener icon and it remains red (is not listening). | Your socket (port_id) might not be available. | Change the port_id in the debug daemon, then change the port_id parameter in the TEST runtime option to match. |
| You start your program on the host, but you see no activity on your 3270 terminal (or a message at the bottom of the screen indicating the connection failed) or you see no activity on the debugger. | Your workstation might not be connected to the network. | From another workstation that is connected to the network, use the ping command to determine if your workstation is connected to the network. |
| z/OS® Debugger starts in full screen mode (a full-screen session appears on a 3270 terminal). For example, you are trying a remote debug mode session from TSO or a CICS® program. | The tcpip_id or port_id parameters are not syntactically and functionally correct. | Review the MVS SDSF log for an allocation failure. |
| You are debugging a batch program (or example, a JES batch job or CICS batch transaction) and it runs without starting a remote debug mode session. | The tcpip_id or port_id parameters are not syntactically and functionally correct. | Review the MVS SDSF log for an allocation failure. |
| You are debugging a batch program and it runs without starting a remote debug mode session. In addition, your z/OS environment is not using the default TCP/IP data set named TCPIP.TCPIP.DATA. | Review the MVS SDSF
log for an allocation failure. Specify the SYSTCPD DD
name with the appropriate TCP/IP data set name. For example, |