RE: Accessing a file in memory

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
mailto:richardjackson@richardjackson.net
www.richardjacksonltd.com
Voice: 1 (303) 808-8058
Fax:   1 (303) 663-4325

-----Original Message-----
From: owner-rpg400-l@midrange.com [mailto:owner-rpg400-l@midrange.com]On
Behalf Of Simon Coulter
Sent: Monday, July 17, 2000 7:54 PM
To: RPG400-L@midrange.com
Subject: Re: Accessing a file in memory


�
Hello Terry,

You wrote:
>One time, I heard the suggestion to create a new shared pool that allocates
>enough memory to load all these files, then use the SETOBJACC specifying
>your new shared pool.  Since nothing else will be using it, all the memory
>will belong to that job.  And then delete the shared pool when you are
done.
>Granted, that is a generic comment and doesn't take into account how much
>memory you really have.

Use a private pool, not a shared pool.  A shared pool will defeat the point
of
SETOBJACC.  Ensure the pool is large enough for the object being pinned.
Other than
that, the general process is correct.

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.                      ��
��������������������������������������������������������������������
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---

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