RE: Interrupting an rpg sql search

Hmmm...

I like....

Will try this out and let you know.

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of rob@xxxxxxxxx
Sent: Friday, January 18, 2008 10:09 AM
To: RPG programming on the AS400 / iSeries
Subject: RE: Interrupting an rpg sql search

Ok, there's multiple ways to skin this cat.
Based on the selection criteria you might just be SOL in trying to tune
access paths.

You could mess with changing the system value for query timeouts, or by
changing the timeout on a job by job basis as I stated earlier (backed up
by another poster). Then your monitor for SQLCOD might have to adapt to
accept that.

Or you could use the email batch one poster submitted.

Another option is to "quasi batch" this. Let's say you have a NEP (Never
Ending Program). It could be out there with an input data queue, and an
output keyed data queue. Your interactive program fires off an entry to
the input data queue. Entry would be some generated key (see UUID APIs)
and your SQL statement. NEP would run the SQL statement and place the
result sets in the output keyed data queue. Your interactive program
would wait on the keyed data queue for only so long. If the entries don't
start arriving back in time then you tell the user to go get stuffed and
try later, or would they like to wait xxx seconds?
The benefit of this process is it offloads a lot of processing to your
batch system. If you pay through the nose for interactive then you won't
be running into that constraint.

Rob Berendt