Batch debug
I frequently used "strisdb" for an interactive debug. But how do you set up a batch debug when several programs run prior to the one you actually need to debug?
Software/Hardware used:
Software/Hardware used:
ASKED:
July 8, 2008 2:48 PM
UPDATED:
April 3, 2011 10:03 AM
Answer Wiki:
Hi,
You can use STRSRVJOB to put the job into "service mode", then use STRISDB the same way as you would normally, but without calling the program :-
STRISDB PGM(Yourlib/Yourpgm) INVPGM(*NO)
Once your program gets called by the batch job, the interactive debugger should start up allowing you to work the same way you do interactively. Remember - you need to run the STRSRVJOB and STRISDB commands from the same interactive session or it won't work.
Regards,
Martin Gilbert.
To see all answers submitted to the Answer Wiki: View Answer History.
Or, from the RSE panel, right-click either the object or the object source you want to debug and select “Set service Entry Point” (also set the userid you want to debug). When the program launches, the debugger interface opens automagically. You can then set monitors, watches, break points,etc. The break points can be saved with the source code.
During debugging, i have noticed the parameter UPDPROD(*YES) which means you are going to update the production files. What kind of files are we referring here? Is it a pf files, lf files, etc? Please help.
..Neon
What kind of files are we referring here? Is it a pf files, lf files, etc?
First, this is a mostly separate question; so it should be asked in a separate thread.
Second, the UPDPROD() parameter works against data files that may be physical (PF) or logical (LF). But they will be *PROD files if UPDPROD(*YES) is required. A *PROD file is one that exists in a library that was created as TYPE(*PROD). See the CRTLIB command to review the TYPE() parameter.
The idea is that a debugging session may involve a programmer changing values in memory in order to affect production data. This can be a serious violation of system and application security and should be controlled. The UPDPROD(*YES) action requires significant authority. By copying data into a *TEST library and running in a test environment, UPDPROD(*NO) can be used; and production files are protected — the system will prevent accidental changes to *PROD data.
UPDPROD(*YES) should be used only with care.
Tom