Re: What is main memory resident?

Hello, all:

Just to add my "two cents"...

I do not believe that the SETOBJACC command actually "pins"
any pages in storage. I believe what it does is a "bring", to force
a "page-in" of all of the pages of a named object. Once this is done,
any subsequent access to these pages should be MUCH faster...
vs. "demand paging" them in, one by one, as needed / referenced.

The idea is, if you really need high-performance and you want the
object loaded by SETOBJACC to "stay" in memory, you can just
create a separate memory pool, using OS/400 storage management.
One of the parameters on the SETOBJACC command is which
POOL you want to "bring" the object pages into.  Then, so long as
no one else is using that POOL, and the pool is sufficiently large,
then none of the pages for your object will get "paged out", and
so, the effect can be almost like "pinning" the pages in memory.

When your application is "done" with using the object, you can
issue the SETOBJACC command again, with POOL(*PURGE)
to free up the main storage in that pool for other uses.

ALTERNATIVES
=============
Another technique that was widely used, both on the System/38
and the AS/400, before IBM added the SETOBJACC command,
was to write a small RPG program that would READ every record
of the FILE, (thus causing the pages to be paged in), and then this
program would set LR=OFF and RETRN, thus staying active and
never ending.  So, this had (more or less) the same effect. If you
wanted to get an object paged-in to a particular storage pool, you
simply had to arrange it so that this RPG program ran in a job queue
attached to a subsystem assigned to that storage pool.

When you wanted to "purge" the pages, you could just call this little
RPG program with a parameter to tell it to terminate, and it would
set LR=ON and RETRN (exit normally).


Yet another technique that I have seen used is to create a *USRIDX
and read the data from the *FILE, and populate the *USRIDX, and
then use the FNDIDXEN MI instruction (or equivalent APIs) to
retrieve from this "table". Of course, if the contents of the *FILE are
ever updated, you need to run a program to "refresh" the *USRIDX;
this can easily be automated by attaching a native "trigger" program
to the base table *FILE.  (The assumption here, which I believe is
correct, is that using the FNDIDXEN instruction or API is much
faster than using standard HLL Database I/O instructions, which
calls through several levels of OS/400 I/O routines, etc., to get to
the data, copy it from buffer to buffer, etc.)

Hope that helps...

Regards,

Mark S. Waterbury


----- Original Message -----
From: "Walden H. Leverich" <WaldenL@TechSoftInc.com>
To: <mi400@midrange.com>
Sent: Thursday, July 25, 2002 9:13 AM
Subject: RE: [MI400] What is main memory resident?


> You could "pin" the object in memory using setobjacc, but I've never
> completely understood the need for that command. If you're using it so
often
> that you need it in memory then it's probably in memory already since it's
> used so often. If it's not in memory from use then you probably don't use
it
> enough to need it in memory.
>
> Also, I'm not sure you can tell if a "real" physical read occurred. I
don't
> know of a spot where the OS tells you that it had to read the row from
disk
> as opposed to memory. Remember, with single level store everything is "in
> memory" to most of the OS, except the lowest level stuff. Is there
something
> in performance tools maybe?
>
> -Walden
>
>
> ------------
> Walden H Leverich III
> President
> Tech Software
> (516) 627-3800 x11
> (208) 692-3308 eFax
> WaldenL@TechSoftInc.com
> http://www.TechSoftInc.com
>
> Quiquid latine dictum sit altum viditur.
> (Whatever is said in Latin seems profound.)
>
>
>
> -----Original Message-----
> From: Kaare Plesner, SOSY A/S [mailto:kaaple@attglobal.net]
> Sent: Thursday, July 25, 2002 02:33
> To: MI400@midrange.com
> Subject: [MI400] What is main memory resident?
>
>
> I have a case where I need to know if a bunch of records from a data base
> resides in main memory when I want to access them. I can indirectly make
> intelligent guesses by checking if there are any physical reads when I
> access these records, but I would like to actually verify this. I am
looking
> for something like the good old mainframe dump of a given part of storage.
>
> (I know (and agree) that the "Single level storage" philosophy should mean
> that you normally wouldn't and shouldn't care, since OS/400 brings into
> memory what you need and when you need it.)
>
> Can anyone assist? - could be some MI code, but an existing OS/400 tool
that
> I have overlooked might be easier.
>
> Kaare Plesner        I     SOSY A/S
> mailto:kp@sosy.dk    I     DK-2730 Herlev
>                      I     Denmark
>
>     SOSY A/S - an IBM Business Partner
>       Meet us at http://www.sosy.dk/
>
> _______________________________________________
> This is the MI Programming on the AS400 / iSeries (MI400) mailing list To
> post a message email: MI400@midrange.com To subscribe, unsubscribe, or
> change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/mi400
> or email: MI400-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/mi400.
> _______________________________________________
> This is the MI Programming on the AS400 / iSeries (MI400) mailing list
> To post a message email: MI400@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/mi400
> or email: MI400-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/mi400.
>