Correction.
< Our S/38 only had 1gb of memory
Our S/38 only had 1mb of memory.
We've come a very long way.
MB to GB to TB.
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Steinmetz, Paul
Sent: Friday, April 06, 2018 11:19 AM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Memory pool , object question
Excellent article.
Here's another.
https://homes.cs.washington.edu/~levy/capabook/Chapter8.pdf
<Correct, in memory is in memory
< once in main memory, resources are available to every job, no matter the storage pool the resource is in.
If this is true, then why not simply have the machine pool and *BASE?
Would be great to get some sort of confirmation on this.
Subsystems, routing entries, classes, control the priority, timeslice, purge settings, not memory pools.
Memory pools control the activity levels.
Here's an actual true story.
Customer wanted to improve their performance. They had all spinny disks. They worked with their BP, upgraded to all SSD.
They saw NO improvement in performance.
Both the BP and the customer were now scratching their heads.
They got MPG to do some performance analysis.
The customer was already using SETOBJACC.
Customer never informed the BP, the BP never thought of asking.
I feel I can improve the performance of some long running batch jobs. Some of these run multiple times per day.
What's the solution?
SETOBJACC, Keep in memory (KEEPINMEM), combination of both.
I'm considering the use of SETOBJACC, especially once the P9 arrives with ample memory.
SETOBJACC needs to point to a storage pool.
The objects being considered for SETOBJACC might be used by both interactive (*INTERACTIVE) and batch (*SHRPOOL1) My thoughts were run everything out of *BASE, SETOBJACC would point to *BASE.
Years ago, as Evan mentioned, memory was at a premium and there wasn't much of it.
Our S/38 only had 1gb of memory, and every job needed a good piece of the pie, thus a lot of paging/page faults.
Today, with ample memory, very little paging.
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Charles Wilt
Sent: Friday, April 06, 2018 9:25 AM
To: Midrange Systems Technical Discussion
Subject: Re: Memory pool , object question
Interesting article...
https://db2fori.blogspot.com/2013/10/in-memory.html
Charles
On Fri, Apr 6, 2018 at 7:21 AM, Charles Wilt <charles.wilt@xxxxxxxxx> wrote:
On Fri, Apr 6, 2018 at 5:17 AM, Vernon Hamberg
<vhamberg@xxxxxxxxxxxxxxx>
wrote:
SETOBJACC provides a way to preload a table or index or program -
it's especially useful for doing random access to data without any disk I/O.
It's not something to use for everything - that'd be impossible
Well now-a-days, not impossible...in-memory DB's are all the rage
after all....just very expensive! ;)
Charles
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
Help support midrange.com by shopping at amazon.com with our affiliate link:
http://amzn.to/2dEadiD
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
Help support midrange.com by shopping at amazon.com with our affiliate link:
http://amzn.to/2dEadiD
midrange.com
