× 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.




Vern,

I'm not clear on what exactly you'd like me to do.  I've never checked the
optimizer while running a program in debug.  Are you asking me to setup the
batch program for debug, set a break point at the beginning of the program,
run the program, and when the break point hits just release the break point
and let the progam run, then look at the job log after the progam
completes?

Frank






vhamberg@xxxxxxxxxxx@midrange.com on 04/20/2005 04:27:54 PM

Please respond to Midrange Systems Technical Discussion
       <midrange-l@xxxxxxxxxxxx>

Sent by:    midrange-l-bounces@xxxxxxxxxxxx


To:    Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
cc:

Subject:    Re: Interactive SQL faster than Batch SQL?


In addition to what David said, it would be interesting to run each job in
debug - you can do the batch one with STRSRVJOB of the batch job on hold or
in a held job queue. The optimizer could be choosing different ways to
process the statement. Let us know whether you can do this and what results
you get. The optimizer messages will be in the job log.

Vern

-------------- Original message --------------

> fkany@xxxxxxxxxxxxxxxxxx wrote:
> > When I submit an SBMJOB an SQL RPG program, it takes almost an hour to
> > process. When I manually run the SQL statements using STRSQL, the
> > processing takes about 10 minutes.
>
> Interactive jobs run at a much higher priority than batch jobs.
>
> The theory is: Interactive jobs need to run very fast while they are
> running, but a majority of their time (CPU wise) is spent waiting for a
> user to respond. Thus they run fast for very short periods of time.
>
> A batch job, on the other hand, needs to have systems resources for a
> longer period of time, but it doesn't need to run as fast because a user
> isn't sitting behind a screen waiting for a response.
>
> There's more too it, but I think that's a pretty reasonable summary.
>
> david
>
>
> --
> David Gibbs
> david@xxxxxxxxxxxx
>
> Receipt of this message does not grant you permission to send me
> Unsolicited Commercial Email




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.