Current versions (even relatively recent versions) allow for a COBOL debug file to be a "side file". There is even SOME support for debugging programs compiled with OPT. HOWEVER< if you want to use debug tool as a source code debugger, then you will want to compile with NOOPT, which is certainly NOT what you should promote into production (IMHO).
All of the 3rd party debuggers have differing amounts of support for debugging programs compiled with OPT. However, in general, I still recommend doing unit testing with NOOPT and a source code debugger - and then your final tests with OPT turned on. For a discussion of Debug Tool and COBOL "OPT" debugging, see: http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/c1911961/6.6.3 For information on suboptions for the TEST compiler option (including "SEPARATE" to have a separate side file), see: http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/c1911961/2.2.1 "Paul Peplinski" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > I am looking at converting to IBM Debug Tool V8.1 (Ent Cobol 3.4, soon to be > 4.1). My first impression is that Debug Tool puts debug control into the > load module (or points to it in the case of an external symbol dictionary). > That seems incompatible with our development strategy where a program is > compiled once and then promoted through the hierarchy. My concern is > promoting bloated and unoptimized modules into production or needing to > share symbol files across environments (i.e. test and QA) especially when > those programs might have different working storage. > > Does this product dictate compiling at each stage with a final NOTEST > compile going into production? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
