Debugging back-end web jobs on the System i with RDI

[robert.swanson]

Anyone interested in getting started with using RDI to interactively debug their Valence/Web 2.0 back-end programs should watch this short video webcast (https://pentontech.webex.com/ec0509l/eventcenter/recording/recordAction.do?theAction=poprecord&confViewID=1141017&rnd=5087967613&siteurl=pentontech&servicename=EC&recordKey=676AB61B519BDA1BBE99855661F54E070CFFC15E 502D17F0954D7E90D5DB4103&RecordingID=114101) from IBM. It explains how to use a “service entry point” in RDI when debugging Valence programs, or any other RPG program for that matter. It's incredibly easy and programmer-friendly, light years ahead of using STRDBG or any other green screen equivalent.

Be sure to use the correct user ID on your service entry point. For most Valence programming, that's QTMHHTP1 (unless you have user switching activated, in which case it's the user ID your Valence profile is linked to).

[jp2558]

I agree. This debugger is light years ahead of the others. I've been using it for over a year now and would never go back to the others. The debugger alone is the biggest reason to use RDi/WDSCi.

However, regarding the following statement"

"Be sure to use the correct user ID on your service entry point. For most Valence programming, that's QTMHHTP1 (unless you have user switching activated, in which case it's the user ID your Valence profile is linked to)."

I've found this to be a bit problematic. We started playing with the user switching (which will be required for all of our applications), but the problem is that the debugger only initiates under the qtmhhtp1 profile since that is the active profile when the program initiates. It's not until the program is actually executing that the profile swap occurs. This is a problem since I and another programmer are often debugging different applications that apparently share the same CGI job/thread and we are unsure as to how do further isolate the job so that we can be sure we are actually debugging the correct job.

[richard.milone]

Hi jp2558, a couple members of the Valence Development Team are now looking at how the RDi debugger reacts to Valence user switching. Someone should post back a response today.

[sean.lanktree]

Be sure to specify a service entry point that takes place after the user switch has occurred (assuming you are debugging for the switched user).
The user switch occurs in the second instance of the vvDevelop copy source within the Valence program.

Below is a simple example of how a program would look that makes use of the user switching feature within Valence:


** Program Name: ABC123
**
f* Customer Master by Customer#
fdemocmast if e k disk usropn

**--------------------------------------------
** d specs
**--------------------------------------------
d action s 20a

** internal procedures...
d SendCustRecs pr

/define OVERRIDE_JOB_USER
/copy qcpylesrc,vvDevelop
**--------------------------------------------
** program start
**--------------------------------------------
/free
vvSessID=vvHttp_in('sid');
/copy qcpylesrc,vvDevelop //this is where user switch occurs
action=vvHttp_in('action');
if action='SendRecords';
SendCustRecs();
endif;

/copy qcpylesrc,vvDevelop
*inlr=TRUE;
/end-free
***-------------------------------------------
p SendCustRecs b
d SendCustRecs pi
/free
// do something
//
/end-free
p e


The actual user switch would take place during the second copy of vvDevelop (just under "program start"). Thus, in order to debug the job for the switched user, you must specify a point after the switch occurs.

When setting a service entry point, we can specify a particular procedure to set it in. But before specifying the procedure, we must specify what module the procedure resides in. In my example, I am going to debug program ABC123 (source above) running under user JOE.
In the Set Service Entry Point window, I specify:

ABC123 as the program


ABC123 as the module. I could either type this in or press browse and select it.


SendCustRecs as the procedure. I could either type this in or press browse and select it. In this case, it would show me every procedure within the selected module ABC123. In the case of ABC123, I would see two modules: SendCustRecs and ABC123. Procedure ABC123 represents the mainline code, beginning with the vvDevelop copy source that switches the user. If I select this procedure it will never break under username JOE because when the mainline is executed it is still running under QTMHHTP1.


JOE as the user ID.


http://www.cnxcorp.com/forum_images/2008-12-23_1806.png

Accept the service entry point and you are ready to debug program ABC123 running under switched user JOE.