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"
<Peter.Connell@xxxxxxxxxxxxxxxxxxxx> wrote in
message
news:1E3D2A8B3A31AD409EA2A4EC19B817998CE969@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Barbara,
> Regarding the performance of using data areas.
>
> We still use data areas to increment unique numbers (I know that V5R2
identity columns a now worth a serious look).
> 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.
Since the data areas are often not related to each other from an application
perspective this may be just a consequence of too much CPU load where there
is some low level code that cannot grab an release a data area fast enough.
>
> I have always been under the impression that data areas are objects
designed to be so simple that they lend themselves readily to processes that
require the rapid update of a value such as a counter by multple processes.
It has been suggested to me that using a file would eliminate such a locking
issue but am very suspect of the overhead (for system data management
processes) and struggle to believe that anything can be faster than a data
area especially if the input/output statements are consecutive lines of
code.
>
> Peter
>
> -----Original Message-----
> From: Barbara Morris
[mailto:bmorris@xxxxxxxxxx]
> Sent: Thursday, May 29, 2003 11:31 AM
> To: rpg400-l@xxxxxxxxxxxx
> Subject: Re: data area question
>
>
> "Shrader, Patrick" wrote:
> > ...
> > Code (V4R5):
> > D period         uds                  dtaara(PROCYR)
> > D  cmonth                        6s 0
> > ...
> > Data area definition:
> >                                Display Data Area
> >                                                              System:
> >  Data area . . . . . . . :   PROCYR
> >    Library . . . . . . . :     FILLIB
> >  Type  . . . . . . . . . :   *DEC
> >  Length  . . . . . . . . :   6 0
> >  Text  . . . . . . . . . :   Processing Year and Month
> >  Value . . . . . . . . . :   200312
> >
>
> Patrick, by putting the DTAARA keyword on the DS line, you've defined it
> as a character type.  Put the dtaara keyword on the numeric variable
> itself.  You can't code the U since it's not a DS, so you'll have to
> read and write it yourself using IN and OUT.
>
> D  cmonth          s             6s 0 dtaara(PROCYR)
>
>  * If you just want to read the value:
> c                  IN     cmonth
>
>  * If you also want to change the value:
> c     *LOCK        IN     cmonth
>    ....
> c                  OUT    cmonth
>
> _______________________________________________
> 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.
>
> This correspondence is for the named person's use only.  It may contain
confidential or legally privileged information, or both. No confidentiality
or privilege is waived or lost by any mistransmission. If you receive this
correspondence in error, please immediately delete it from your system and
notify the sender. You must not disclose, copy or rely on any part of this
correspondence if you are not the intended recipient. Any views expressed in
this message are those of the individual sender, except where the sender
expressly, and with authority, states them to be the views of Baycorp
Advantage.If you need assistance, please contact Baycorp Advantage on either
:-
> Australia 133124 or New Zealand +64 9 356 5800
>
> _______________________________________________
> 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.
>
>