RE: Accessing a file in memory

SETOBJACC can load your objects into ANY pool. But if there is not enough
space there, or if this is a truly SHARED pool, you objects will be
eventually paged out defeating the purpose of the exercise. SETOBJACC does
not turn any main storage pool into either a HW or a SW cache for a specific
object. It's a one-off action of loading object pages into the main storage.

There is nothing wrong with 90% CPU utilization as such. It only becomes a
problem when app.. 70% is used by response-time critical jobs. 

As far as I remember,  new (output) object pages do not inherit its
SETOBJACC characteristic and are written to the pool of your job.

I'm yet to see a definitive list of performance tips and techniques that
would help you avoid paying a performance consultant when your AS/400 is in
trouble.

Lo

> -----Original Message-----
> From: James W. Kilgore [SMTP:eMail@James-W-Kilgore.com]
> Sent: Tuesday, July 18, 2000 4:59 PM
> To:   MIDRANGE-L@midrange.com
> Subject:      Re: Accessing a file in memory
> 
> Simon,
> 
> Thanks for your insight.  I admit I spend most of my life, now, above
> the MI so I have a virtual viewpoint of the AS/400.  And I "might not"
> hone in on the finer details of actual execution. (I'm not nearly as
> good at multi-tasking, but I am gaining speed on loss of differentiating
> reality from viewpoint) =:-}
> 
> IMHO, the AS/400 is so rich in capabilities, I was attempting to raise
> more questions of points to consider than provide answers.  There are a
> myriad of situations and points to consider that I don't think that
> there can be a "one size fits all" kind of answer.
> 
> But from what you've contributed I'm reading between the lines that it
> still boils down to beg the question: do you have enough memory to place
> the files in memory?  By system method or user method.
> 
> But you've piqued my curiosity about the finer details about main
> storage cache (which is the way I view cache) and system cache.  Which
> place does SETOBJACC go to?
> 
> In reading the help text there is some reference to SETOBJACC using a
> pool that contains no other jobs.  Does this mean that is sort of like a
> virtual floppy drive?  Oops, I dated myself :-)
> 
> From what I've read it can be a user defined shared pool, so long as
> nothing else uses it.  Sort of contridicts the definition of "shared".
> 
> Now, Simon, I'm not picking on you, but most of my clients are running
> 90+% CPU as is and if SETOBJACC, properly set up, will gain them
> performance I'm all for it.  Where can I go to get information beyond
> the "how-to" to the "why/why not"?
> 
> TIA
> 
> 
> 
> 
> 
> Simon Coulter wrote:
> > 
> > h
> > Hello James,
> > 
> > You wrote:
> > >I read some of the other responses and started thinking (bad thing on a
> Monday
> > >;)), but if you have enough memory to place the files into memory, then
> why
> > >aren't they staying in cache?  So I'm not sure if you have enough
> memory for
> > >SETOBJACC to work for you.>
> > 
> > Main storage is effectively a cache for DASD on the AS/400 but that is
> not the same as
> > the system cache (by which I assume you mean the processor cache?).
> SETOBJACC will
> > provide an improvement if enough main storage can be dedicated to the
> pool containing
> > the objects.
> > 
> > >AFAIK, user space is just space and may not reside in memory.
> Remember, under
> > >single level storage disk and memory are the same thing.>
> > 
> > Main storage and DASD are not the same thing.  Single-level store may
> make them appear
> > to be the same but that is only from one particular viewpoint.  View
> storage from above
> > the MI and it all appears the same.  That is one of the things that
> makes programming
> > the AS/400 so simple.  However, the machine still needs to make the
> distinction.  If
> > your use of "MAY not" means "MIGHT not" then your statement is true, if
> you mean "CAN
> > not" then it is wrong.  All AS/400 objects must be in main storage
> before they can be
> > processed -- like any other computer (The S/38 had storage-to-storage
> instructions but I
> > don't believe the RISC system do -- they need their stuff in registers).
> SETOBJACC lets
> > you tell the system what you care about.
> > 
> > >If you don't have enough memory for SETOBJACC to work for you, I'm not
> sure that
> > >making the files into tables would help much either.  You may just be
> changing
> > >-what- is being swapped.
> > 
> > In the sense of a table as an array rather than an SQL table it will at
> least improve
> > the likelyhood of the needed program storage being available in main
> storage rather than
> > on DASD.
> > 
> > Regards,
> > Simon Coulter.
> >
> +---
> | 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
> +---
+---
| 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
+---