Restrictions for debugging an assembler program

When you debug assembler programs the following general restrictions apply:
  • Only application programs are supported. No support is provided for debugging system routines, authorized programs, CICS® exits, and so on.
  • Debugging of Private Code (also known as an unnamed CSECT or blank CSECT) is not supported.
  • To debug subtasks that are started by the ATTACH macro, delay debug mode must be in effect. Subtasks that are started by the ATTACH macro can be debugged in one of the following circumstances:
    • If the main task starts in a non-Language Environment program, the task must be started by calling EQANMDBG and supplying the TEST option. For more information, see Starting z/OS Debugger for programs that start outside of Language Environment.
    • If the main task starts in a Language Environment program, or if a Language Environment program is the first program to be debugged, you must specify the TEST run time option (for example, via a CEEOPTS DD statement).

    For more information, see Debugging subtasks created by the ATTACH assembler macro.

  • You cannot debug programs that do not use standard linkage conventions for registers 13, 14, and 15 or that use the Linkage Stack. Not using standard linkage conventions or the Linkage Stack can cause the following commands to function incorrectly:
    • LIST CALLS
    • STEP RETURN
    • STEP (when stopped at a return instruction)
    • %EPA
  • Debugging of programs that use the MVS XCTL SVC is not supported.
  • Debugging of the 64-bit Language Environment®-enabled and Language Environment XPLINK programs is not supported.
  • CICS does not support 64-bit programs interfacing to CICS services; therefore, z/OS® Debugger does not support debugging of 64-bit programs under CICS.
  • Support for binary and decimal floating-point items requires 64-bit hardware and Decimal Floating Point hardware (for decimal floating point support).
  • If your current hardware does not support 64-bit instructions or your program is suspended at a point where the 64-bit General Purpose Registers are not available, the 64-bit General Purpose Registers are not available and any reference to symbols for the 64-bit General Purpose Registers are treated as undefined.
  • The 64-bit General Purpose Registers are available only in the compile unit in which z/OS Debugger is stopped at a breakpoint. If you use the QUALIFY command to qualify to a compile unit higher in the calling sequence, the 64-bit General Purpose Registers are not accessible.
  • When your program is suspended in a compile unit, that compile unit is the only one from which you can access the 64-bit General Purpose Registers. If you use the QUALIFY command to qualify to a different compile unit, you can no longer access the 64-bit General Purpose Registers.
  • Debugging of programs that use Access Register mode is not supported.
  • Debugging of programs that use the IDENTIFY macro or service is not supported.
  • You cannot debug programs that were assembled with features that depend on the GOFF option, for example, CSECT names longer than eight characters. If the program can assemble correctly without the GOFF option, then you can debug programs that are assembled with the GOFF option.
  • If you are debugging a program that uses ESTAE or ESTAEX, the program behaves as if TRAP(OFF) were specified for all Abends while the ESTAE or ESTAEX is active, except program checks. In other words, no condition is seen by z/OS Debugger. Any Abends except program checks are handled by the ESTAE(X) exit in your program.
  • If you are debugging a program that uses SPIE or ESPIE, the program behaves as if TRAP(OFF) were specified for all program checks while the SPIE or ESPIE is active, except a program check that might arise from the use of the CALL z/OS Debugger command.
  • The debugging of TSO Command Processors is not supported.
  • If you start debugging in a non-CICS load module that is not the "top" load module, you cannot continue debugging after that load module returns to its caller. In order to do this, you must invoke z/OS Debugger using CEEUOPT or some other internal method. You cannot do this by using JCL alone.
  • Debugging of assembler or disassembly code requires the use of the Dynamic Debug Facility. z/OS Debugger does not support the use of the Dynamic Debug Facility to debug code that is not known to the z/OS Contents Supervisor. This can occur in situations similar to the following situations:
    • Debugging load modules loaded by a directed LOAD.
    • Debugging segments of code which have been relocated. For example, a GETMAIN is used to obtain a new piece of storage. Then a section of code is moved into this new piece of storage and control is passed to it for execution.