Re: Rép. : Re: AW: How do you debug CGIDEV2 programs

Denis/Vern,

The trouble is, if you have a lot of CGI HTTP server jobs going, you can't
be sure which one will actually process a request from the browser. For
instance, even if a web page is initially served by one job, when that page
is submitted (because a submit button is pressed in a form), you can't
guarantee that the input will be sent to the same CGI HTTP server job - the
main HTTP server jobs will just send it to the first CGI job that is
available (not currently processing input). On a 'unloaded development
system, you can often have only a single CGI job going, so you can be sure
that it will process the input, but in a production environment, you can't
be so sure.

A while back (6 years ago!) I wrote an article about a utility I wrote (
http://www.iprodeveloper.com/article/rpg-programming/lets-pause-for-a-moment-17999)
to do a 'nicer' equivalent of the 'add a DLYJOB' workaround. I still use
this, but to be honest, the SBREAK method is really the only way (short of
using PAUSE or something like that which adds code)to be sure that the job
will stop at the correct point in the program code, since it's not
restricted to the job in which the program is run

Rory

On Fri, Aug 10, 2012 at 4:14 PM, Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>wrote:

Denis

Nice technique - SEP technique can lead to many messages in the initial
job that started debug - and they have to be released so that the users
are not blocked. On a production system, this is something that could be
messy.

So your idea lets you selectively do the debugging, right?

Vern

On 8/10/2012 10:09 AM, Denis Robitaille wrote:

Since I was unaware of this technique to find out the complete job

name/number, I used the following work around:

I have the CGI program write the job info to the web page as hiden

variable. Then I just display the HTML source and the STRSRVJOB required
info is there for me. I can then proceed with the STRSRVJOB and STRDBG.