RE: Normalization was Left AS/400 and Returned -- MIDRANGE-L

This will vary widely, based on load and how many accesses you have. I recently spoke with one of our customers that reported orders of magnitude improvement. The key to this is, anything in memory in whatever pool is available to all jobs on the system, no matter the pool they are running in. Memory access is much faster than disk access. If you could put all your data, and possibly programs, in memory, you'd really fly.

One thing to be sure to do is to make SETOBJACC preload the file or files into a *FIXED pool, not *CALC. Also, no jobs should be allowed to run there, as that could force purging to disk.

I think this is basically the same as preloading an array, just on a larger scale. BTW, inserts to a file end up in the pool, too.

Results will also vary, because once one user has brought a record into memory, it is available to every job. So the benefit of SETOBJACC might not be as great in a very busy system with lots of access to the same data from separate jobs. Of course, data can be paged out, whereas the SETOBJACC stuff will not be.

HTH
Vern

At 02:43 AM 5/6/2005, you wrote:

Hi Joe

I understand that the SETOBJACC command allows a file to be "pinned" (cached might be a better term) in memory to avoid multiple disk accesses. Have you ever experimented with what performance benefits might be obtained using this method instead of the slightly less direct method of transforming the file into an array ?

Anyone else got any benchmarks or experiences ?

I'm just curious , not trying to prove a point or anything ;)

Regards
Evan Harris

And I understand your preference.  Checking every date by doing a CHAIN
or SETLL on a file is easy.  I think part of my bias is that I come from
a scheduling background, which means I need information for periods,
rather than single days.  I might have to schedule an operation to run
over 10 days, and thus I'll have to know all the working days.  By
reading a one-year array once, I'm covered and I can schedule all the
work for that item.

With a one-record per date approach, I'll be doing lots of I/O, over and
over again (unless I read the data from the file into an array, at which
point your argument about how hard it is becomes moot).

I guess my point is that I think you need to look not only at the data
but also at how it is used when determining the normalization of a
database.

Joe


--
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,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.