Using the STDEBUG Command

You can use the STDEBUG command to trace calls to storage management to determine what caused a storage problem, such as an out of storage condition, storage fragmentation, or storage overlays. With the trace enabled, you can trap CMSSTOR, DMSFREE, DMSFRET, FREEMAIN, and GETMAIN requests providing you with the following information:
  • Amount of storage obtained or released
  • Address of the storage obtained or released
  • Address of the caller to storage management
  • Name of the subpool the storage is allocated on.

See the z/VM: CMS Commands and Utilities Reference for details on the STDEBUG command.

The STDEBUG command also lets you control the caller address range to be traced, the storage address range (the area where storage is being obtained or released from) to be traced, and the list of subpools to be traced. Therefore, you can generate the data only needed to perform the debugging operation.

For example, when a program in a known storage location requires debugging, it is not necessary to trace all the calls to storage management within the CMS nucleus. You can limit the trace to only the calls made within a specific storage address range.

Another example is when a repeatable error condition, such as a program exception, occurs when you run your application after an abend or IPL. This can happen because data (such as a branch address) is retrieved from a storage location that is no longer allocated. By limiting the trace to only the address range of the storage that is supposed to contain valid data, you can easily identify who obtained and released the storage.