Re: GET DIAGNOSTICS question

On Wed, 10 May 2023 at 21:22, Reeve <rfritchman@xxxxxxxxx> wrote:

Charles, thanks. WRT to your suggestion of sleeping regardless, I'm
pricing orders entered moments before and there is a sense of urgency/not
getting backlogged with the pricing process. If I get to the end of the
data, I want a quick check to see if any new data has shown up. That's the
point where I want to tickle SQL and find out if new orders have arrived.

There are multiple ways to implement 'sleep at each NODATA'.
1) Hard code a value that fits the minimum delay your environment will
accept. Maybe it's 1 second
2) Put the value in a data area so the delay can be observed and
adjusted without interrupting the process
3) Have your pricing process adjust the data area up and down based on
demand. Bump it up (to a reasonable maximum) if you price a few
records, and bump it down (to a reasonable minimum) if you've
processed many. This way, at slack hours, the process waits longer
before waking up. 'Few' and 'Many' can also go into a data area so
that you can experiment dynamically
4) Have the pricing process vary the delay based on time of day

It can be surprising how effective a simple hard coded delay can be.
Much depends on the specific load the process of OPEN / FETCH (NODATA)
/ CLOSE adds to the machine. If the CPU spikes to 90%, you probably
don't want to do that 86,400 times a day. But if it only adds 1%, do
you care how often the process wakes up to check for data? So... try
it in your environment. Generic patterns only go so far when it comes
to performance advice.
--buck