Use them infrequently but have discovered one technical difference between the use of a *DTAARA and a table.

If you write to a *DTAARA the system forces the write to disk. Now if you have write cache on your disk controllers the write to that cache is considered 'well enough' and processing continues. However if you have no cache (as a low end system with mirrored disk might have) then the write must be actually to disk. When using for a 'next order' number and such things this is no problem, however if you are updating the *DTAARA with (say) current record position in a massive table (for crash recovery for example) then EVERY record position gets forced to disk and that slows the job *DRAMTICALLY. If you are using a table or traditional database file then the O/S caches that data preventing every write from hitting physical disk.

Potentially a rare case I grant you but finding it out at 2AM (when I did) was not pleasant.

- Larry "DrFranken" Bolhuis

On 5/13/2011 11:17 AM, Birgitta Hauser wrote:
Hi guys,

we just had a discussion about using data areas.

In my opinion they are not heavily used or needed.

I either create a table/physical file or store the information in global
variables in a specific service program. The data within these global
variables is set and retrieved by calling procedures.

I’m just curious, are you using data areas (heavily) or not?

Mit freundlichen Grüßen / Best regards

Birgitta Hauser

"Shoot for the moon, even if you miss, you'll land among the stars." (Les

"If you think education is expensive, try ignorance." (Derek Bok)

"What is worse than training your staff and losing them? Not training them
and keeping them!"

This thread ...


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

This mailing list archive is Copyright 1997-2019 by 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].