RedMage1967
Programmer
I found this article on the web a couple of months ago. It really has helped me in finding program errors.
LET THE DEBUGGER SHOW YOU WHERE THE USER'S PROGRAM HAS FAILED.
When a user calls to let you know that one of your RPG programs has just crashed and that there's an error message on their screen (or in a message queue for batch jobs) that's awaiting a response, don't be too hasty in having them respond. If your program has a debugging view that shows you the statements and if the program isn't optimized, here's a handy diagnostic technique. With the error message still unanswered, first determine the qualified job name (job name, user and job number) of the problem job and the program with the failure. You can use various commands such as WrkActJob or WrkUsrJob to find this information (to find the program in error, examine the call stack looking for the last user-written program). Next, from your command line, start a service job with the command StrSrvJob specifiying the qualified job name of the problem job as the job to service. This lets you enter debug commands for that job. After starting the service job, enter the StrDbg command specifying the problem program you identified and press Enter. Voila! The debugger displys the program in error and is positioned to the line of code that precipated the error. How's that for ease? You can then explore the situation in the debugger and solve the user's problem more quickly. You'll also know right where to go to fix the bug! When finished debugging, end your debugging session with EndDbg and end the service job with EndSrvJob. The user can also respond to the message now! RedMage1967
IBM Certifed - RPG IV Progammer
LET THE DEBUGGER SHOW YOU WHERE THE USER'S PROGRAM HAS FAILED.
When a user calls to let you know that one of your RPG programs has just crashed and that there's an error message on their screen (or in a message queue for batch jobs) that's awaiting a response, don't be too hasty in having them respond. If your program has a debugging view that shows you the statements and if the program isn't optimized, here's a handy diagnostic technique. With the error message still unanswered, first determine the qualified job name (job name, user and job number) of the problem job and the program with the failure. You can use various commands such as WrkActJob or WrkUsrJob to find this information (to find the program in error, examine the call stack looking for the last user-written program). Next, from your command line, start a service job with the command StrSrvJob specifiying the qualified job name of the problem job as the job to service. This lets you enter debug commands for that job. After starting the service job, enter the StrDbg command specifying the problem program you identified and press Enter. Voila! The debugger displys the program in error and is positioned to the line of code that precipated the error. How's that for ease? You can then explore the situation in the debugger and solve the user's problem more quickly. You'll also know right where to go to fix the bug! When finished debugging, end your debugging session with EndDbg and end the service job with EndSrvJob. The user can also respond to the message now! RedMage1967
IBM Certifed - RPG IV Progammer