ADSM-L

Re: OS390 TSM Performance questions.

2003-02-14 08:25:59
Subject: Re: OS390 TSM Performance questions.
From: Richard Sims <rbs AT BU DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 14 Feb 2003 08:21:54 -0500
>I followed your discussion with much interest, as I'm suffering from
>huge performance problem problem too. Unfortunately I'm not under OS390,
>but using AIX 4.3.3 : could someone tell me if there is some some trick
>like this one, that should be considered, when using this OS ?

Arnaud - Your posting did not say whether you've first pursued the
         recommendations in the TSM Performance Tuning Guide.
If you are not also the AIX systems programmer at your site, you
should confer with those people to have them review the environment
in which you are running.  In http://people.bu.edu/rbs/ADSM.QuickFacts
I've collected various performance factors to check for.

Rather than looking for "tricks", it is far better to master the facets
of your hardware and software environment, and thus have a solid grasp
of maximum performance capabilities so as to recognize when things
aren't working right and know what to do.  Anything from overloaded
SCSI adapters to misconfigured ethernet connections can be a factor.

I can't stress strongly enough one major aspect of implementing systems
that novices always overlook: doing a benchmark, first.  It is vital
that you "road test" whatever you implement before committing it to
production.  At a minimum, that should be your basis for accepting
hardware and software from vendors, to see if they measure up to
brochure specifications.  Simple example: a printer which the vendor
states will run at 100 pages per minute.  If you don't initially test
it, to discover that it ony produces 82 ppm when printing duplex,
you're going to be in frantic mode when full-load printing comes
along.  The basic principle is that you MUST first assure that new
hardware and software can perform at expected levels before committing
them to production so as to be certain of their capabilities, and thus
to truly know what is normal and what is abnormal when a problem
situation occurs.  And repeat your measurements if at all possible
when doing firmware or microcode upgrades to avoid unpleasant
surprises.  Never assume that newer stuff is better: it may indeed
have been created by someone equally new in the vendor company.

  Richard Sims, BU