RE: FNDSTRPDM memory enhancement -- MIDRANGE-L




I had never even heard of SETOBJACC before.  I went through the help on it
and this is probably what I am looking for.  This is probably how FNDSTRPDM
"caches" members in main memory.  I wonder when these get purged from main
memory.  It is cached for some time and then you have to start all over the
next day.  Should I use the same storage pool that FNDSTRPDM is already
using?  I'm not sure how to find out what storage pool FNDSTRPDM uses.  Can
we see the objects stored in main memory?  I would probably run the
SETOBJACC by member but I am not sure whether I should use the *BASE or
*SHRPOOLn and what pool identifier.
>> Thing is, you need enough space that is not needed for running
processes.
Are you saying that I could cause other jobs to slow down or possibly
abort?  If space ran out, would old storage purge as newer storage gets
added?  I want to make sure I avoid slowing down any important jobs since I
would be adding members in main memory that may never take advantage of
being in main memory.  Does adding objects to main memory decrease
available storage?

The reference to a memory location in a job probably explains why a newer
version of the program would not take effect until it is run again.
I'm not sure if I would be decreasing available storage for other jobs.
I think you are probably right about the read bringing in the member for
small members.
I guess the question about whether I am crazy or not is still open.  :)

Thanks,
Craig Strong

** Vern wrote:
Craig, have you looked at the SETOBJACC command? It is the fastest way to
get objects into main memory. You can (need to?) specify members for files.
Your loop could use this on the members listed.

Look at the help text on this command, esp. the opening section, for hints
on making these things persistent in main memory. Thing is, you need enough
space that is not needed for running processes.

The replaced object thing is a little different - there's probably some
reference to a memory location in your job, and if a program is in use
while it is recreated, that reference is changed to the copy in QRPLOBJ.

Once an object is in memory, it is available to all running processes, even
if in a different pool.

If the member is small enough (probably < 4k), 1 read is enough to bring it
all in. This depends on things like expert cache, which can use larger IO
block sizes for sequential file access, which could be the pattern for
source members. But the normal block size is one memory page, or 4096
bytes.

HTH

Vern

BTW, you still might be crazy. Just because a person is paranoid, it
doesn't mean they're not really after you.

At 11:34 AM 10/10/2003 -0500, you wrote:
-snip-

If you open each member in an RPG program, do a single read, and
close, I think that places the entire member in memory.


-snip-

Every morning a system scan is initiated in batch that basically does a
DSPFD for all common source physical files to outfiles.  I was thinking of
taking these resulting outfiles and submitting jobs to batch for each
library processed for each source file.


-snip-

Should I do the open, 1 read, close of every source member in batch jobs (1
library per job)?  Any system issues that might come up in doing this?
Am I correct in thinking of this as members stored in memory?  Is this the
same thing as when a program is replaced while someone is using it and they
are running the version still stored in memory until they exit?
Am I crazy?

Thanks,
Craig Strong