How about good afternoon! My name is Domingo and I am 26 years old, I have just entered the world of IBM and lately I have had a problem in the company where I work, I hope here I can find the answer, what happens is that I have a doubt, I have added
this line to an RPG program Qcmd= 'CHGJOB RUNPTY(10) PRCRSCPTY(*HIGH)'; which in test environments gave me a higher performance of the execution of the pgm lasting 1 hour, but I did not have the same luck in production since it lasted 3 hours (it should
be noted that the execution of this program is night when there is no user connected ). At first I thought it was the ptf but I made sure that the ptf of the production and testing environment were at the same level. I still gave it the same priority on
both servers and timeslice but it didn't work either, it still results in higher performance on the test server while in production it seems to ignore it. Do you know what is due? Both servers are power 9

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Do u also have same lot of memory in the subsystem, u where you run the PGM ? Try to run the PGM in bach. SBMJOB CMD(CALL PGM(PGM)) JOBQ(QBATCH)

R.


Il giorno lunedì 7 novembre 2022 alle 18:39:07 UTC+1 Jomi Hernandez ha scritto:

How about good afternoon! My name is Domingo and I am 26 years old, I have just entered the world of IBM and lately I have had a problem in the company where I work, I hope here I can find the answer, what happens is that I have a doubt, I have added

this line to an RPG program Qcmd= 'CHGJOB RUNPTY(10) PRCRSCPTY(*HIGH)'; which in test environments gave me a higher performance of the execution of the pgm lasting 1 hour, but I did not have the same luck in production since it lasted 3 hours (it should
be noted that the execution of this program is night when there is no user connected ). At first I thought it was the ptf but I made sure that the ptf of the production and testing environment were at the same level. I still gave it the same priority on
both servers and timeslice but it didn't work either, it still results in higher performance on the test server while in production it seems to ignore it. Do you know what is due? Both servers are power 9

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, November 7, 2022 at 12:39:07 PM UTC-5, Jomi Hernandez wrote:

How about good afternoon! My name is Domingo and I am 26 years old, I have just entered the world of IBM and lately I have had a problem in the company where I work, I hope here I can find the answer, what happens is that I have a doubt, I have added

this line to an RPG program Qcmd= 'CHGJOB RUNPTY(10) PRCRSCPTY(*HIGH)'; which in test environments gave me a higher performance of the execution of the pgm lasting 1 hour, but I did not have the same luck in production since it lasted 3 hours (it should
be noted that the execution of this program is night when there is no user connected ). At first I thought it was the ptf but I made sure that the ptf of the production and testing environment were at the same level. I still gave it the same priority on
both servers and timeslice but it didn't work either, it still results in higher performance on the test server while in production it seems to ignore it. Do you know what is due? Both servers are power 9

Hi Domingo,
IBM calls this Work Management.

I urge you to speak with someone who has experience on that specific machine to give you advice.

Performance tuning is one of those things that tends to be platform specific. The things that tune a Windows server or program simply don't apply to an IBM i system or program. And I assure you that any advice you found to tune an AS400 does not apply to
IBM i. It's not just a new paint job - the work management has been very much rewritten in the 20 years since AS400 was made.

I've been tuning IBM systems, applications, and programs for 30+ years. If you want to get into this area, read the Work Management manual, then read it again. That second reading will make more sense after you have seen all of the subjects once. Learn
how to run Performance Explorer to gather statistics. Learn how to read PEX reports and interpret the results. The first rule of tuning: Measure, record, plan, change one thing, record, and measure again. Now you have the before and after, for any one
change, and you can start to piece together how the various configuration elements interact for the workload on that particular hardware/software combination. Try to keep in mind that even if you are tuning one single program, when that program runs, it
becomes part of the system workload, part of the ecosystem. If you change the priority of one job above all the others, you are starving all the other jobs of cycles.

I know, you said it runs at night with no other work on the system. If that's true, then you've just learnt the second rule of performance tuning: don't tune it unless you have to. If it's running alone on an unloaded system at night, it's unlikely to
need tuning.

So:
1) Don't guess. Measure!
2) Don't try random things. Understand what each thing does.

--buck

ps as a thought exercise, what does priority mean when there's only one job on the system?
pps the advice to run the program in a batch subsystem is good advice. Why?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello Buck,

Buck <[email protected]> wrote:

And I assure you that any advice you found to tune an AS400 does not apply to IBM i. It's not just a new paint job - the work management has been very much rewritten in the 20 years since AS400 was made.

In strongly disagree. While IBM did substantial changes under the the hood, the basic principles still apply:
- Paging platform, paging globally, and not per application. RAM = Cache.
- Confine paging to subsystems/memory pools to adjust relative performance of
jobs against each other competing for common resources.
- Adjust activity levels to prevent thrashing and keep DASD latency low. Most
often, DASD is shared globally so this easily becomes a major bottleneck.

What *has* changed from a sysadmin point of view is that RAM and CPU cycles are available in abundance for years now and production machines are rarely that severely memory constrained as they were in 1990. My personal experience
over 15 years working with the system showed that most often, it's perfectly sufficient to just enable dynamic resource adjustments at run time only by setting QPFRADJ to 3, and enable expert cache with PAGING(*CALC). And let the system decide for itself where resources are needed and what do to about it.

I've been tuning IBM systems, applications, and programs for 30+ years. If you want to get into this area, read the Work Management manual, then read it again. That second reading will make more sense after you have seen all of the subjects once.

I agree. Also there are some books on the subject, I'd recommend:
- Chuck Stupca - iSeries and AS400 Work Management
- Fielder, Machell - Supercharging the AS400, A Guide to Performance Management - Michael Catalani - AS400 Performance Tuning Simplified

These not only show what's important for memory constrained AS/400's, but the authors manage to explain the mysteries behind subsystems, and memory pools. Concepts not known from common systems. Yes, they are rather dated but as explained above, the same principles still apply. Although not to the extent shown, because of much much more memory nowadays.

Learn how to run Performance Explorer to gather
So:
1) Don't guess. Measure!
2) Don't try random things. Understand what each thing does.

A very important advice!

:wq! PoC

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)