Re: Accessing a file in memory

["Simon Coulter" <shc@xxxxxxxxxxxxxxxxx>]

"
Hello Richard,

I don't think there is any point in using SETOBJACC if you can't give it enough 
memory 
to contain the object.

Your comments on "hot" and "cold" paging are correct as far as they go but 
isn't that 
what happens to an object anyway under normal paging conditions?  SETOBJACC 
doesn't 
really pin the object in main storage -- it just loads it into specific 
storage.  The 
difference is that pinned pages don't get paged.

When a job requests data that isn't currently in main storage that data is 
loaded into 
storage allocated to the subsystem in which the job is running.  If the data is 
already 
in main storage, even if it is in a different pool, it is simply USED from 
there.

So if you load an object in to a sufficently large private pool it will stay 
resident 
and be accessible from all jobs.  If, as you suggest, the pool isn't large 
enough then 
SETOBJACC will bring the object in to the pool and replace earlier loaded pages 
with 
later pages.  You end up with a partially loaded object.

I'm not sure, but I suspect that activity on the loaded object that causes more 
pages to 
be brought into main storage will go to the job's pool not the SETOBJACC pool.  
Thus 
defeating the exercise.

A similar problem occurs if the object has new space allocations, e.g., adding 
new 
records.  The new data is paged into the job's pool, not the pool specified on 
the 
SETOBJACC command.

SETOBJACC is really only useful for frequently accessed data that is fairly 
static and 
that can be loaded entirely into main storage.

Regards,
Simon Coulter.

«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»
«» FlyByNight Software         AS/400 Technical Specialists       «»
«» Eclipse the competition - run your business on an IBM AS/400.  «»
«»                                                                «»
«» Phone: +61 3 9419 0175      Mobile: +61 0411 091 400           «»
«» Fax:   +61 3 9419 0175      mailto: shc@flybynight.com.au      «»
«»                                                                «»
«» Windoze should not be open at Warp speed.                      «»
«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»
//--- forwarded letter -------------------------------------------------------
> X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
> Date: Tue, 18 Jul 2000 07:53:11 -0600
> From: "Richard Jackson" <richardjackson@richardjackson.net>
> To: RPG400-L@midrange.com
> Reply-To: RPG400-L@midrange.com
> Subject: Accessing a file in memory
> Importance: Normal

> 
> Simon:
> 
> Agreed except ...
> 
> If the pool isn't big enough, the object will page normally in and out of
> the private pool.  Since the object paging isn't in response to competition
> with other objects, the "hot" parts of the object will stay in memory and
> the "cold" parts will leave.  If access has distinct hot and cold patterns,
> this will provide the best balance between access time and memory space.  If
> access is random - has no hot and cold pattern - a higher faulting rate will
> occur but if it is the only object in the pool, you can't do any better.
> 
> If multiple objects are pinned into the same private pool, this advantage
> goes away at a rate proportional to the _fault_ rate in the pool.  Remember,
> database doesn't normally fault to bring in pages, it uses bring, so
> database faults are bad.
> 
> Experiment with pinning the mort important logical files into memory.  You
> could avoid all index page faults.  Indexes are usually smaller than the
> physical and access patterns for index pages are usually non-random.
> 
> Richard Jackson

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---