Re: data area question - performance

["Booth Martin" <Booth@xxxxxxxxxxxx>]

I'd take the logic one step farther I believe, although it is now moot with
the latest release.  

I'd add a ADD-*before trigger to the file and that ADD program would do the
incrementing   There's no need for doing incrementing in an application
program, ever, and as you've discovered it has lots of potential pitfalls
and maintenance headaches.
 
 
 
---------------------------------------------------------
Booth Martin   http://www.MartinVT.com
Booth@xxxxxxxxxxxx
---------------------------------------------------------
 
-------Original Message-------
 
From: RPG programming on the AS400 / iSeries
Date: Thursday, May 29, 2003 6:45:13 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: data area question - performance
 
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? Depending on how your wait times
are set, switching to a database file could both increase and decrease the
number of timeout errors.
 
The advantage of putting the logic in a service program is that it is then
centralized in one place. This allows you to ensure that all applications
are using a consistent approach, that the method used is optimal, and that
any changes that need to be made to the logic need only be made once.
Scattering this logic throughout your applications is a recipe for problems
.... like you've got. Any tiny performance degradation that results from
switching to using a service program compared to inline code is absolutely
negligible compared to the impact of, for example, one application updating
the data areas incorrectly, e.g. leaving a data area locked.
 
The main argument against the use of data areas, IMHO, is the fact that they
cannot be journaled or processed under commitment control. I guess whether
this is a concern for you or not has got a lot to do with whether the
numbers you're generating just have to be unique or whether it important
they are both unique AND sequential, with no gaps. If the former, then a
data area is probably OK. If the latter, then commitment control and
journaling strikes me as important.
 
My personal preferred approach is to have a single database file whose role
it is to control the allocation of unique sequential numbers. This file
basically has a "number id" field and a "last number used" field. All
numbers are then generated by calling an API, passing in a "number id" and
getting back a new number. The API uses the file to generate a new number.
 
Pete
 
 
"Peter Connell"