Re: Accessing a file in memory

h
Hello James,

I see both Lo and Dave have given some answers.  Let me just say this:

>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.

Well, the system method only pages in what you need thus allowing main storage 
to be 
avaliable for other data.  SETOBJACC allows you to force certain behaviour due 
to your 
more intimate knowledge of the situation.  Performance is all a question of 
resources.

>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?

SETOBJACC loads into main storage.  It will allow you to use any pool you like 
but I 
think a private pool is the only sensible approach.  It is the AS/400's 
implementation of 
virtual memory that makes main storage a big DASD cache.  Most other systems do 
it 
differently and main storage is a cache for the swapper.

>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 :-)

Yes.  There is little point to using SETOBJACC to load into a pool that is in 
use.

>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".

That's my view too!  And it is too easy to assign a shared pool to some other 
use thus 
destoying any SETOBJACC advantage.

>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"?

Better bloody not be picking on me :)

SETOBJACC is unlikely to reduce CPU usage since it generally affects I/O rates. 
 But as 
Lo says there is nothing inherently wrong with using 90% or more of the CPU.  
The 
performance problems arise from the queuing that occurs when the CPU is flat 
out.  There 
is a paucity of "why" information available from IBM.  I get mine from years at 
IBM, reading and thinking and testing and attending sessions by the likes of 
Chuck 
Stupca, etc.

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 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
+---