RE: Subsystem and memory pools

Rob:

IBM gave a couple of pools specific names, just to be straightforward, there
is nothing special about those pools vs. any other.

*CALC is almost always going to give you better performance, the system is
smarter about paging than we are, so I tend to always assume it's on. It's
really rare it gets turned off, and then I have not done it without IBM
support suggesting that it would be a good thing. It happens, but rarely.

Most folks don't understand the function of the routing in the job
description and how it gets to the proper class and memory pool like you do,
and every time I teach it at COMMON I get veterans of the system tell me
they never really understood it until then. Yes you can do as you're
suggesting, in fact I do it all the time.


--
Jim Oberholtzer
Agile Technology Architects


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Rob
Berendt
Sent: Friday, December 15, 2017 10:08 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: RE: Subsystem and memory pools

Is there really nothing unique about a memory pool, other than the name?
Sure the size also.
But other than size or name?
For example, shared vs calc on the paging? Are certain loads better in one
than the other?

Is there a reason to have jobs with certain contentious job properties out
of the same pool? For example, are any of the attributes shown in DSPJOB
OPTION(*RUNA) contentious between jobs of other settings?
Or subsystem routing entries utilizing different classes (WRKCLS)?
After all, it is the subsystem routing entry which determines what pool to
run a particular job in.

On our main production box QBATCH has two pools. Subsystem pool 1 points to
*BASE. Subsystem pool 2 points to *SHRPOOL1. Some of the subsystem routing
entries say use subsystem pool 1 and some say subsystem pool 2.


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail
to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com

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