× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Sean

In a way it doesn't matter - every job will be interrupted when the SBREAK line is encountered.

Of course, if in a production setting, this means that you delay EVERY job at that point, until you release it in your job. With CGI jobs, this can result in a timeout, in my experience.

So, again, in an environment where there will be many users coming in to a server like the HTTP server, you want to identify which job you are truly interested in. If you do the STRSRVJOB for the first one, you may receive many more messages while working on that first job, and all of them may need releasing - my use of alternate job isn't as handy here, probably a second session on a second monitor is better, since then I will see the messages.

Vern

On 8/11/2012 2:13 AM, McGovern, Sean wrote:
Rory,

Does it matter that there may be multiple jobs ? As long as STRDBG and SBREAK is used, the program will break at the appropriate point regardless of which job is currently being used.

Sean

________________________________________
From: rpg400-l-bounces@xxxxxxxxxxxx [rpg400-l-bounces@xxxxxxxxxxxx] on behalf of Rory Hewitt [rory.hewitt@xxxxxxxxx]
Sent: 11 August 2012 01:29
To: RPG programming on the IBM i / System i
Subject: 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.
--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.