RE: data area question - performance

[Buck Calabro <Buck.Calabro@xxxxxxxxxxxx>]

Peter said:

>We still use data areas to increment unique numbers 
>However, when the iSeries is under heavy load (90% up) because 
>of poor performance in certain applications, it appears that 
>we get problems with completely separate jobs because they 
>cannot get a lock on a data area. 

Pete mentioned:

>It strikes me that this has very little to do with the 
>relative efficiency or inefficiency of updating data 
>areas and database files.
>
>This surely has much more to do with the fact that 
>your applications are running slowly and that the 
>time that locks are being held on your data
>areas is exceeding the default wait time?

I've worked with applications on S/38 (old/slow) that use data areas to
generate the next invoice number/check number, etc.  Even with the machine
at 99% CPU we had no performance issues with the data areas.  This isn't a
guess on my part; it's substantiated by many runs of Performance Tools.

Almost all locking problems are a result of holding the lock too long, like
this:

in
exfmt
add 1
out

If the user goes to lunch during the EXFMT, the lock is held for a very long
time indeed, and the next job wishing to use the data area will wait (and
ultimately throw an error of the wait time is exceeded.)  Try to change the
code to minimise the time the program holds the lock.  Here's one way:

in
add 1
out
exfmt

I'm not certain of your exact problem, but I would strongly suggest using
which ever incarnation of performance tools/explorer/ops nav you have
available so that you can gather solid data about where the time is being
spent.
  --buck