Debugging your source code during the development of your applications is a critical function of software development, which is why your COBOL development system is capable of debugging a wide range of source, using a wide range of techniques, such as automatically invoking the debugger when your application fails, or attaching a debugger to a waiting application. See Debugging scenarios for an overview of the different types of techniques, and when you might want to use them.
You can debug both native and JVM COBOL sources, and also debug applications that consist of mixed programming languages. These source files can also be local to your computer or stored remotely (with the use of Micro Focus Enterprise Developer UNIX Components).
You debug most applications by simply running them under debug conditions; however, on certain Linux platforms, it is possible to capture a program's behavior in a recording, and then replay that recording on another machine, giving you all the debug information that you would have if you were running it locally. There are many other ways in which you can debug an application; all of these are discussed in more details in the Debugging scenarios section.
To debug any application, it must be compiled for debugging. This will ensure that it generates a symbols (.idy) file during compilation; this file contains all the necessary environment settings to allow the source to run through the debug engine. Preparing sources for debug does cause an overhead and so the final production version of an application usually has debugging turned off. You can use launch configurations within a project that are specifically configured with the intention to debug; see Running and debugging.
Eclipse contains a perspective specifically designed for debugging - the Debug perspective. It contains a lot of useful views as you debug, such as ones containing the call stack, the variables and watchpoints, and breakpoints lists. It also contains the controls required to navigate through your program's execution, allowing you to run through the program until a breakpoint it hit, reverse back through lines of executed code, and examine the value of variables (and even change those values) during every step of execution.