|
Arco,Why would you want to remove it? I can only think of two reasons: size and 'obscurity'.
Size: A program without debug information is smaller. But if you compare the size of an average program library to that of an average database, size is hardly an issue.
'Obscurity': In theory, 'prying eyes' could extract information, sometimes even the complete source, from a debuggable program. But when I think of the time it takes for new programmers to get a reasonable understanding of the programs, I'm not too worried about prying eyes.
Wit a debuggable program on the other hand, if a user encounters an error and is smart enough to call the help desk instead of just cancelling, it is possible with STRSRVJOB and STRDBG to look at the actual data that is causing the error. In some cases it is even possible to change the value of a variable and let the process continue.
Joep Beckeringh Simonse, Arco (CMK) wrote:
I wonder why so much people want to keep debug information with their programs that are moved to production, so considered to be stable? Personally I always do DBGVIEW(*NONE) and OPTIMIZE(*FULL) when applications are tested and approved. If it is neccessary you can always create a new "debugable" programobject isn't it? Just curious.Arco Simonse pgmr
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
