RE: Multiple processors

A single-threaded job can basically use just a single CPU.
Multi-threaded jobs can potentially use more than one.  A
single-threaded job _may_ benefit from >1 CPUs since the job itself may
call on system functions or other external items that can use >1 CPU.

If doing lots of database work, for instance, the DB2/SMP LPP may
benefit.


BTW, a job that is running at ++++ isn't necessarily saturating a CPU.
It could be saturating a virtual CPU or the LPAR's CPU allocation,
neither of which is necessarily equivalent to an actual physical CPU. 

Anyway, as others have mentioned the best approach is to look for the
bottleneck and work to resolve that.
- Are any disks in a failed status or is the disk subsystem 'degraded'? 
- What is the disk % Busy?
- Does the job do lots of comm and if so is the comm line saturated?
- Are tons of journal entries being written?  If so review the redpapers
published over the past few months about journal performance & tuning.
- What memory pool is the job running in and what's the faulting rate?
- How much synchronous v. asynch IO is being done?  If lots of synch is
being done more RAM _may_ help by providing buffer space.  Or a better
RAID card (more cache).
- Ensure the number of virtual CPUs is no greater than the max CPUs
allocated to the LPAR (rounded to the next whole number).  Examples: If
1 CPU is allocated, virtual CPUs should equal 1.  If 1.1 CPUs are
allocated, virtual should be set to 2.
- If possible, allocate CPUs to the LPAR in whole CPU increments and
define then as unchanging.  There's a tad less LPAR resource management
overhead this way.  Probably not enough to notice but it s a couple of
percentage points.
- Is anything in WRKPRB or is there anything 'interesting' in QHST?
- Are there any performance-related PTFs that could be loaded?