Diagnosing problems

If the problem is in the shell or debugger, the system treats it as an application problem.

For information about diagnosing problems, refer to z/OS Language Environment Debugging Guide. There are suboptions for the TERMTHDACT runtime option that enables you to specify the amount of dump data that is to be collected. For more information about the suboptions, see z/OS Language Environment Programming Reference.

If you specify a dump by setting the _BPXK_MDUMP environment variable, you do not have to allocate a SYSMDUMP data set for the TSO/E session. The dump is written to either the MVS™ data set or the specified z/OS UNIX file.

If the _BPXK_MDUMP environment variable is not set, then you can specify a dump by allocating a SYSMDUMP data set for the TSO/E session. The system then does the following:

Creates a file in the user's working directory.
Names it coredump.pid, where pid is the process ID for the process being dumped. It is in hexadecimal format.
Writes a core dump in the file. The core dump is a SYSMDUMP dump.

Setting _BPX_SHARAS to NO causes the output to go to a UNIX file. If it is set to REUSE (or YES), the dump is written directly to the MVS file, and the coredump.pid file is not created.

To use the core dump, follow these steps:

Copy the file into an MVS data set with a record length (LRECL) of 4160, by entering a TSO/E OGET command.
Use IPCS to analyze the dump. (Use the IPCS subcommands STATUS and SUMMARY FORMAT CURRENT.)

You can dynamically request a SYSMDUMP by using the SIGDUMP signal. Use the _BPXK_MDUMP environment variable to specify where the SYSMDUMP is to be written to. You can also use F BPXOINIT,DUMP=pid to request a SYSMDUMP. A SIGDUMP signal is then sent to the specified process. For both the SIGDUMP signal and the F BPXOINIT,DUMP command, the _BPXK_MDUMP environment variable must be set to an MVS data set name. If it is set to a UNIX file name or defaulted to OFF, then both the SIGDUMP signal and the F BPXOINIT,DUMP command might be ignored.