RE: Stored Proc question

["Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>]

> From: SRamanujan@sungardfutures.com
>
> I have an applet that uses a servlet to call a stored proc to
> fetch the data from AS/400.   The stored proc calls another
> process that goes through a lot of calculations and writes to a
> data queue.  The stored proc then reads the data from the data
> queue, which can be anywhere between 10 to 900, creates a result
> set and sends back to java.   So, the wait time for the user on
> the browser is anywhere between 20 seconds to 2 minutes or more!
> depending upon the filter they selected.   When it waits for the
> stored proc, there is no life on the bowser, it goes into a
> trance and the user does not know how long it is going to take.
> Now, is there a way, the stored proc can return a set of  data
> from the data queue say every 2 seconds, go back to read the data
> queue and send the next set of data? ( Because when it returns
> the result set first time, the stored proc thread dies at the
> as/400 end as well as the java end.)  In this way, I could
> probably have a status bar on the screen to show the porion
> completed and keep the user aware.

This simple question actually hits a lot of areas where browsers are
different than 5250 screens.  The biggest one is the concept of "wait time"
and "refresh".

In HTML, there is no standard way to "refresh" the screen like you would
with a FRCWRT in DDS.  However, you can do a refresh and a redirect (using a
timeout value of zero).  If you did this, you could at least return to the
user a wakeup message saying "processing".  Let's get back to that in a
second.

Now, unless you know the total number of records you expect to receive,
there's no good way to determine the actual percentage complete.  All you
can really do is tell the user to hang on, data will be here eventually.

And if that's the case, all you need to do is send a "Waiting" page to the
user, and have it immediately attempt to redirect itself back to the servlet
that's actually doing the get.  That way, the user at least sees a message
that processing is occuring, and once the data is received, the new page
will show up.

With your current setup, that's really all you can realisticaly do without
doing a lot of extra coding.  If you want the user to get a sense of
"movement", you could include an animation GIF on the waiting page that does
something nifty.  This is often enough to stop the user from getting
frustrated and banging the refresh button.

Hope this helps!

Joe