RE: data area question - performance

Nothing can be faster than inline code. A user space would probably be unweildy 
and locking is the primary issue. The best solution must surely reside with 
allowing the compiler to govern the lock.

-----Original Message-----
From: Tom Liotta [mailto:qsrvbas@xxxxxxxxxxxx]
Sent: Thursday, May 29, 2003 1:08 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: RE: data area question - performance


Peter:

Consider using a user space rather than a data area.

In your programs, grab the pointer to the *usrspc at initialization time. Use 
this as a basing pointer for a data structure or element that defines your 
counter.

When you want to get the next number and increment, use perhaps the _LOCK 
builtin to set a lock, do the get/increment, then use _UNLOCK so the next 
process will work. Be aware that the lock won't necessarily prevent another 
process from updating the value, but it can prevent another process from 
obtaining a lock at the same time.

Perhaps put all this into a service program procedure. Ought to be fast enough 
for you.

Tom Liotta

rpg400-l-request@xxxxxxxxxxxx wrote:

>   9. RE: data area question - performance (Peter Connell)
>
>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.

-- 
Tom Liotta
The PowerTech Group, Inc.
19426 68th Avenue South
Kent, WA 98032
Phone  253-872-7788 x313
Fax    253-872-7904
http://www.powertechgroup.com


__________________________________________________________________
McAfee VirusScan Online from the Netscape Network.
Comprehensive protection for your entire computer. Get your free trial today!
http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397

Get AOL Instant Messenger 5.1 free of charge.  Download Now!
http://aim.aol.com/aimnew/Aim/register.adp?promo=380455
_______________________________________________
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