I've not used it in the way you are describing below since there are too
many factors to consider when the program does I/O. What you're suggesting
is not a valuable test since you're not testing how fast the call really is
as opposed to the I/O.
I have put programs up in memory to make access to them faster. Once
customer in Central America had a large retail application. A COBOL program
was calling a pricing program (also COBOL) over thirty times per line item
at checkout. (Let's not discuss the lack of wisdom in that design, it is
what it is) That caused a huge backup at the checkout lines and was
costing sales.
We simply pinned that program in memory and changed how it was called (OPM
to ILE conversion) and it temporarily solved the problem. Back to normal
times for checkout. I then instructed the customer to re-architect that
program stack to avoid having over thirty calls per line item.
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Steinmetz, Paul
Sent: Friday, April 06, 2018 2:33 PM
To: 'Midrange Systems Technical Discussion' <midrange-l@xxxxxxxxxxxx>
Subject: RE: Memory pool , object question
Jim,
Do you have any time savings of your use of SETOBJACC?
I created a 400,000,000 record test file.
Created a simple test program, read the file, beginning to end.
14 minutes to read all 400,000,000 million records.
SETOBJACC OBJ(PAULS/CCEKCPP) OBJTYPE(*FILE) POOL(*SHRPOOL1) 46877104K of
CCEKCPP brought to pool with 25441484K unused.
Reran the same test program.
11 minutes to read 400,000,000 million records.
SETOBJACC OBJ(PAULS/CCEKCPP) OBJTYPE(*FILE) POOL(*PURGE)
Member CCEKCPP purged from main storage.
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jim
Oberholtzer
Sent: Friday, April 06, 2018 1:59 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Memory pool , object question
SETOBJACC has some limitations as well.
IF the object is truly read only such as a program or data area it will stay
in memory. But if the object is updated, such as a file or data queue,
then the system will force it to DASD at some point and it will fall out of
that pinned memory.
I will always use a shared pool like *SHRPOOL60 and start working back from
there since those are really rarely used. No work in those pools except the
objects that are pinned in there.
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Vernon Hamberg
Sent: Friday, April 06, 2018 12:51 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: Re: Memory pool , object question
Paul
I would not put anything into *BASE using SETOBJACC - the article I cited
says these should go into a pool where there is no work, a fixed pool, that
will not be affected by any optimization - you want it static.
It is not just data that is paged in and out of a pool - it is also *PGM
objects - and potentially almost anything else jobs work with. *BASE would
be the place where almost everything will get paged out of main memory
eventually and maybe not before too long a time.
Also be sure not to over-manage this stuff - see that article, again, for
what makes good candidates for this technique.
Cheers
Vern
On 4/6/2018 10:18 AM, Steinmetz, Paul wrote:
-snip-
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.
-snip-
--
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
--
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
