×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
We compile all programs with *LIST for debug, this allows debug at any time with the source the object was compiled with. Works great if a job halts with a message as you can attach to the job with STRSRVJOB and debug with the live values. Sometimes you can adjust the value of a field to allow the program to continue on depending on the type of error.
Scott Mildenberger
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Dean Eshleman
Sent: Tuesday, March 31, 2015 12:44 PM
To: Midrange-L Mailing list xxxx
Subject: Do you compile production programs for debug?
One of our developers asked why we don't compile our production programs for debug. Their thought was, it would make it easier to debug a production process when there was a problem. Currently, when we have a production problem the developer tries to recreate it in a test environment. If they can recreate it, they can debug it there. In the rare circumstance they can't recreate it, we do recompile the program for debug and put it into production. Currently, our developers do not have authority to debug production jobs. A few admin types have this authority, so it can be done.
Anyway, what do other people do. Do your production programs that you write and use in house contain debug information? Are there any negative side effects of doing that? Does it impact performance in any way? TIA
Dean Eshleman
Software Development Architect
Everence Financial
1110 North Main Street
PO Box 483
Goshen, IN 46527
Phone: (574) 533-9515 x3528
www.everence.com<
http://www.everence.com/>
midrange.com
