Re: Interactive SQL faster than Batch SQL?

[vhamberg@xxxxxxxxxxx]

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 
> 
> -- 
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list 
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx 
> To subscribe, unsubscribe, or change list options, 
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l 
> or email: MIDRANGE-L-request@xxxxxxxxxxxx 
> Before posting, please take a moment to review the archives 
> at http://archive.midrange.com/midrange-l. 
>