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