Re: data area question - performance

Beautiful!

Then, even if you do switch to rowid, you've still got only one spot to 
fix logic.

Rob Berendt
-- 
"They that can give up essential liberty to obtain a little temporary 
safety deserve neither liberty nor safety." 
Benjamin Franklin 





"Booth Martin" <Booth@xxxxxxxxxxxx>
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
05/29/2003 09:15 AM
Please respond to RPG programming on the AS400 / iSeries
 
        To:     <rpg400-l@xxxxxxxxxxxx>
        cc: 
        Fax to: 
        Subject:        Re: data area question - performance


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"_______________________________________________
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.