× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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

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

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.