On Wed, Apr 16, 2008 at 9:26 AM, Howard Brazee <[EMAIL PROTECTED]> wrote: > On Tue, 15 Apr 2008 18:03:09 -0700, Paul Knudsen > <[EMAIL PROTECTED]> wrote: > > >>Every once in a while someone pulls up a debugger tool, intending on > >>having that skill in our resume. But when we actually need to debug, > >>we go back to the old way - displays in the code. > > > >Wasting time good for job security. > > Every once in a while, we have time to waste - pulling up debugger > tools is as good of a way to fill that time as any. > <soapbox> If a debugging tool is seen as a "waste of time" it is usually because the installation hasn't put enough effort into tailoring it for local use.
When we installed IBM Debug Tool in our shop, we altered all of our standard compile procs to support the TEST option and to link in the CEEUOPT module when needed. All the programmer has to do is select the TEST option on a panel and provide the VTAM LU of his debug terminal (We are on release 5.1 of DT, a bit back level.....I understand later releases of DT have done away with this requirement). We never use the IBM supplied ISPF dialog to set up our debug sessions. I am not knocking IBM, but their dialog, of necessity, has to be generic, and like all generic tools requires a fair amount of effort to use. We also provided each developer with a private DB2 data base for unit testing/debugging, and developed some in house tools to help them maintain them. This addresses data base contention concerns cause by people sitting at a breakpoint. Finally, we renovated our rarely used BTS environment to accommodate all of these changes. It is the programmer who puts Display messages in the code that is "wasting time" </soapbox> ---------------------------------------------------------------------- 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
