Re: The ASF Resigns From the JCP Executive Committee

As you know, finding problems by debugging live production environments is

a pretty bad technique to use regularly.

What exactly is bad technique about debugging live production environments -
especially since STRSRVJOB/STRDBG+IBMi OS make it so easy? At the risk of
sounding like an un-refined coder, I debug in live production environments
first and foremost (vs. trying to recreate it), because that is often what
can get a customer back online the quickest.

Things like this are what gets lost in newer models of programming stacks,
IMO. And it is also where tons of other tools are necessitated because of
the original issue not being addressed.

Aaron Bartell
www.MowYourLawn.com/blog
www.OpenRPGUI.com
www.SoftwareSavesLives.com



On Tue, Dec 14, 2010 at 9:49 AM, Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx>wrote:

So does that mean I have to stop the server and restart it? I wouldn't
think that is an acceptable practice in a production environment.

Unless they've changed something recently, servers typically run in debug
mode or not. Debug mode allows you to attach a debugger and do your
thing, but it's not without some performance penalty.

The standard practice is to recreate the problem in a test environment in
debug mode. As you know, finding problems by debugging live production
environments is a pretty bad technique to use regularly. Sometimes it's
unavoidable, but it's not recommended. The only time you do that is when
you can't recreate the problem.

In that case, you need to run your production environment in debug mode
until the problem occurs. Then you can attach and debug.

Joe
--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.