1. Work Management & Performance
Chapter 14

2. Overview
The AS/400 combines the pieces of Managing Devices, Working with Jobs, and Working with Subsystems to run programs
Pieces fit together – performance testing

3. What makes a job run? 6 necessary things: Devices Job Descriptions
Job Classes
Job Queues
Subsystems with:
Routing entry(s)
Job queue entries – batch SBS
Workstation entry(s) – interactive SBS
Communication entry(s) – communication SBS
A valid user ID or password
6 necessary things:

4. How the AS/400 runs Interactive Jobs Batch Jobs WS device known
Valid sign-on
SBS with job description and class
WSE
Routing Entry
Batch Jobs
How batch jobs are started:
SBMJOB
Communication PGM start request
Auto-start jobs
Pre-start jobs

5. How the AS/400 runs Communication Jobs
A hybrid between interactive and batch jobs
Remote system start
Communication entry needed

6. Subsystems
QBASE and QCTL
SYSOPR should:
QCMN
QINTER
QBATCH
QSPL

7. Performance
AS/400 has ability to constantly “tune” resources while jobs are running
Document all efforts

8. Automatic Performance Tuning
Two system values
QDYNPTYSCD
prevents gobbling resources
QPFRADJ
manages pool memory allocations
Manual monitoring is still a good idea

9. Why Manually Monitor?
DPS is quick to reset changes priorities after they have been lowered
SYSOPR may want it low
SYSOPR may want a PGM to be a “hog”
Sometimes user response-time complaints are due to transmission time across a busy or large LAN. (AS/400 performance tools don’t address this because it takes place outside the AS/400)

10. Emergencies – What do I do?
An operator should be concerned with 2 areas:
Overall CPU %
Over 100% indicated by ++++
CPU % for individual jobs

11. WRKACTJOB

12. Why is CPU % high? 3 Reasons Programs are complex
Page faulting is causing a lot of extra disk IO
Overall load on the system (# of jobs) is too high

13. Recommendations Vs. Reality
IBM recommends:
below 70% for single-processors
Below 81% for a four-way processor
Systems without noticeable performance problems will typically run in the 90% range
Remember: CPU utilization over 90% gets hammered from excessive seize/lock conflicts

14. What Next?
CPU % over 90% - even if normal - continue searching for problem within the AS/400
CPU % good (approx 75%), hang-up may be due to lost device on LAN
Response time problem + low CPU %
Suspect LAN

15. Work With Active Jobs Example
Largest CPU % - F16 re-sequences by specified column
Some programs need a lot of “horsepower”
Confirm big jobs are necessary (while holding - 3)
If necessary, lower the job priority (higher #)

16. Problem still exists? WRKSYSACT (Work System Activity)
Screen refreshes every five seconds
System tasks and their CPU % is displayed
Don’t normally appear on WRKACTJOB screen
Cancel the user job and the system tasks will go with it

17. Emergency Aftermath New priorities require time to take affect
Recovery period could cause worse damage
LAN failure – disconnect users, sessions dumping logs and cleaning up after themselves
lots of activity
Announcements – “Sign back on”
Performance will die – 15 to 45 minutes

18. TIPS Develop guidelines for performance emergencies
Always use Performance tuning
Monitor performance during busiest time
Modify system parameters (changing activity levels or memory) during less busy times
REMEMBER: Monitoring is an ongoing process
If the System Operator has the AS/400 properly tuned, performance emergencies are less likely to occur

19. TIPS (Cont.)
Performance Tools/400 has powerful data-collecting and reporting tools
STRPFRMON
ADDPFRCOL
ANZPFRDTA
PRTTNSRPT
Best/1 is a built-in capacity-planning product
Use SETOBJACC to preload entire files into dedicated pools for certain kinds of processing

20. AS/400 Servers Tuned to favor batch processing, leave them that way
A few WS will make the interactive CPU % go to 10% and then nothing will run well
IBM recommends less than 2% of the interactive CPU %