× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.