× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On my way to an airplane. I'll write something up in flight.

--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Welly
Soegiantoro
Sent: Sunday, February 15, 2015 6:06 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Paging option of *FIXED vs *CALC

Hi Rob,
When I was an SE I tried changing form *FIXED to *CALC and vice versa... In
some cases it will make the system freeze around more than half an hour...
but I know it depends on the how heavy the usage is...


And Jim, How do you find the problem if you just looking @ the summary...
Can you describe more about it?


--
Thanks

Br,

Welly Soegiantoro
Central Operation Technology
CUG : 367090

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jim
Obeholtzer
Sent: 14 Februari 2015 0:16
To: Midrange Systems Technical Discussion
Subject: Re: Paging option of *FIXED vs *CALC

Rob,

The weekly review I suggest is done by running the system report from
Performance tools and looking at the summary. It takes me about 1 hour to
go through about 40 partitions for various customers. I print the report
from a job schedule entry. 70% of my time is switching from customer to
customer VPN connection. The only time you react much is if there is a
complaint of some sort forwarded or if you see a memory pool starting to
page/fault more than normal.

90% of the time when that happens it's time to review the indexes on the
system to see if there's an index or two that need to be built due to
changes in the data usage.

On Fri, Feb 13, 2015 at 10:27 AM, <rob@xxxxxxxxx> wrote:

Jim,

I was looking at your recommendation of not allowing QPFRADJ to
automatically adjust in order to avoid constant query reoptimization.
Then you make a recommendation for a weekly review.
Well, if I have to pour through performance data the odds of this
weekly review getting done weekly drop.
What about the possibility of this?
Add two job schedule entries. One to change QPFRADJ back to automatic.
One to turn it back off. The second one being two hours later. Maybe
run 9-11am on Tuesday mornings?


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





From: "Jim Oberholtzer" <midrangel@xxxxxxxxxxxxxxxxx>
To: "'Midrange Systems Technical Discussion'"
<midrange-l@xxxxxxxxxxxx>
Date: 12/30/2014 12:52 PM
Subject: RE: Paging option of *FIXED vs *CALC
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>



Paul,

I suggest you consider your use of the automatic tuning function
(QPFRADJ).
For more traditional applications and batch processing this is a good
setting. It will migrate memory from pool to pool as needed, with
some limitations.

However if your application suite uses SQL in any meaningful way, then
it's likely that setting is hurting more than helping. One of the
things the SQL optimizer looks at when starting the optimization
process is "did my environment change?". If not run the query, if it
did, then optimize to be sure the query runs as fast as possible.
QPFRADJ almost forces every query to optimize every time since the
environment by definition is changing. In an environment where quite a
bit of SQL and particularly remote SQL (Zend, WAS, and several other
ways of doing remote SQL) then a steady environment will make these
queries more efficient.

I would say that 90% of my customers run better with QPFRADJ off, and
an occasional (meaning weekly) look at the performance statistics to
see if there is an adjustment needed.

--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Steinmetz, Paul
Sent: Tuesday, December 30, 2014 11:19 AM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Paging option of *FIXED vs *CALC

*CALC for all, machine cannot be changed, forced to *fixed.
QPFRADJ = 2

During the day, most memory is moved to *interact for users.
During evening and night hours, memory moved to *SHRPOOL1 for large
batch processing.

There is also a setting or feature that added improved performance if
set to *CALC.
I can't remember what this was called.

Work with Shared Pools

System:
PENCOR05
Main storage size (M) . : 200704.00



Type changes (if allowed), press Enter.



Defined Max Allocated Pool -Paging Option--

Pool Size (M) Active Size (M) ID Defined Current

*MACHINE 22077.42 +++++ 22077.42 1 *FIXED *FIXED

*BASE 18888.82 1714 18888.82 2 *CALC *CALC

*INTERACT 92082.62 3999 92082.62 4 *CALC *CALC

*SPOOL 3010.55 30 3010.55 3 *CALC *CALC

*SHRPOOL1 64644.56 30 64644.56 5 *CALC *CALC

Paul


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Mike Cunningham
Sent: Tuesday, December 30, 2014 11:26 AM
To: Midrange Systems Technical Discussion
Subject: Paging option of *FIXED vs *CALC

It has been some time since we have looked at this option so I decided
to review this setting for storage pools. We have always found in the
past that *FIXED performed better for us and that is how we have all
pools set at the moment. I think the last time we evaluated this
setting was back pm V5R4 and we are now at 7.1 (we skipped 6). We
have 7 pools setup. Besides *MACHINE and *BASE we have *INTERACT ,
*SPOOL and three Shared Pools. *INTERACT is mostly traditional 5250
but also some jobs that we run all day doing
interactive type transactions. One shared pool runs only ODBC/JDBC tasks
from a system running on Linux but using DB2 as its database. Second
shared pool is for QBATCH work. Third shared pool is for WTR jobs.
*BASE runs everything else. (HTTP, Websphere, Zend, QCTL, QSERVER,
QSYSWRK, QUSRWRK and a few 3rd party tools - Curbstone, Websmart,
GoAnywhere.

We do not have any real performance issues with the exception of an
occasional SQL requests coming on from the Linux systems via ODBC,
where it will spike the CPU for a 4-5 seconds. And some outgoing JDBC
requests from a job running on the i OS and getting data from a MS
SQL system.

I have not seen many articles after 2010 on this setting and those I
did find say to use *FIXED for 5250 work and *MACHINE and *CALC for
anything doing only database (aka ODBC) tasks or do batch type work.
"back in the day" IBM's recommendation was to try each setting and see
which performed better and use that one. We found that *FIXED worked
better for us.

QPFRADJ is setup to No Adjustment.

What do others run for these settings and for what type of workload?

Thanks


Mike Cunningham
VP of Information Technology Services/CIO Pennsylvania College of
Technology


--
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: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take
a moment to review the archives at http://archive.midrange.com/midrange-l.

--
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: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take
a moment to review the archives at http://archive.midrange.com/midrange-l.


--
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: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take
a moment to review the archives at
http://archive.midrange.com/midrange-l.



--
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: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take
a moment to review the archives at
http://archive.midrange.com/midrange-l.


--
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: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.




--
Disclaimer :
Confidential information may be contained in this message. If you are not
the intended recipient, you are strictly prohibited and may be unlawful to
use, copy, store, distribute, disclose or communicate any part of it to
others and you are obliged to return it immediately to sender or notify us
and delete the e-mail and any attachments from your system. Opinions,
conclusions and other information in this e-mail that do not relate to the
official business of any PT Bank OCBC NISP Tbk shall be understood as
neither given nor endorsed by it. No assumption of responsibility or
liability whatsoever is undertaken by PT Bank OCBC NISP Tbk in respect of
prohibited and unauthorised use by any other person.

--
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: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.