Wesley:

Heres some resources to help you in your quest for performance knowledge.   
As you can see from the responses from multiple very knowledgeble sources, 
its as much art as science due to each site's uniqeness in hardware, database 
structure/locks/access methods, batch job (jcl) organization and priority 
queue's, programming languages, and how each program was written.

I would recommend looking at Robert Lunds Performance manuals if you can 
get your hands on them.    Some items have changed with different hardware, 
but basic concepts for tuning and identifying are still sound.

You also might want to look at http://www.aics-research.com/relperf.html 
which is one of the better performance charts I've seen for HP3000's of any 
tier.

I have found some hard fast rules:
   
A)  More memory is better..... especially in light of the costs.   If you are I/O 
bound, not going to help for that process, but not everything is I/O bound and 
will use your extra memory.

B)  Intelligent distribution of your heavily used databases/files across multiple 
Drives and I/O paths yields excellent results.  (You can move database files 
easily with MPEX).  Add more SCSI cards if you have the slots, SCSI cards are 
cheap.  More paths equates to greater throughput.

C)  CPU upgrades do not always pay for themselves, mainly in light of the 
licensing upgrade costs for software if you move up in tiers.   (Don't think you 
have this problem   http://www.openmpe.org/HPe3000SoftwareTiers.htm)

D)  Knowing your databases and applications is always a wise investment.   
Have tuned month end schedules that ran 2 days to 6 hours just by 
resorting/changing database primary paths right before streaming the 
schedules, then putting back afterwards.    Many of the HP3000 applications 
and databases were written with online transaction speed in mind, not batch 
processing.   Sloppy dataset lock programming is another common problem.

E)  Compiling (or really pre-compiling), heavily used 4th Generation language 
code.  Better yet, re-write it in a 3rd GL language if it's a pig.

F)  Intelligent usage of your system.   Don't schedule backups when everyone 
is logging on first thing in the morning.  That kinda thing.   Move heavy CPU 
jobs to offtimes if you can, or you can retune and make good use of the ES 
queue for those quick and dirty, need CPU now jobs.  Penalize heavy CPU 
online users by dropping them in the CS queue.

G)  Hardware RAID pays for itself over software raid in most cases.  Especially 
come recovery time.   Gives you back CPU and memory during the rest of the 
time.

Main thing you need to do is identify where your machine is spending it's 
resources and whats using them.   Glance and SOS can help you chart system 
performance if you have either of those.  Go after the heavy hitters.

Also just because you do your homework once and Identify you have a CPU 
problem, don't expect to be done if you upgrade.   Keep your reports/utilities 
in place because your bottleneck tends to move as you fix things.  You may 
not have a I/O problem now, so you upgrade the CPU, then find out the 
bottleneck is now I/O, or memory.  Those reports also help you justify and sell 
your latest hardware need to the bean counters.

Hope this helps, and either way, have fun learning and exploring!   

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *