Yes I was wrong once... and then smoke filled the laboratory......

In the case we really got pounded the *DTAARA is not journaled. The access was from within an RPG program not a CL CHGDTAARA. The program wasn't ending it was retrieving journal entries and posting the entry number to the data area. (then doing other work with the data) All prior tests had been run on systems with RAID disk and therefore disk write cache. When we hit the first system with no write cache is when we identified the problem. The two drives in the mirrored pair that had the *DTAARA on it were at 100% busy while the other 4 pairs sat at 5%. Soon as the *DTAARA was changed to a single record DB file we were off to the races.

- Larry "DrFranken" Bolhuis.

On 5/16/2011 2:21 PM, Charles Wilt wrote:
You have my utmost respect but even doctors can be wrong ;)

And it was 2am....just thinking what you think you saw wasn't the whole story...

In other words, maybe it's not that every update of a data area is
forced to disk in an of itself...maybe the data area was journaled and
the journal entry was being forced to disk....or the program doing the
update ended after every update and that cause the data area to be
forced to disk (CHGDTAARA vs. RPG access perhaps?)...

IBM says the following about data areas:
To provide a field that is easily and frequently changed to control
references within a job, such as:
- Supplying the next order number to be assigned
- Supplying the next check number

Again, it doesn't seem to make sense to use them in that manner if
every update to them causes a physical disk IO.


On Mon, May 16, 2011 at 1:37 PM, DrFranken<midrange@xxxxxxxxxxxx> wrote:
It wouldn't seem to make sense to do so if Larry's correct about the
overhead of writing to them.
Note that it's not truly 'overhead' but rather the way it gets to
disk. If you've got cache you're good but without it repeated writes to
the same *DTAARA translate to repeated writes to disk where repeated
writes to a Row in a Table don't, UNLESS you close the file every time!

Oh, and *IF*.....? Perhaps you'd better watch over your shoulder
during your next round of PTFs, the Dr Demands respect. :-)
- Larry "DrFranken" Bolhuis
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives

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].