ADSM-L

Re: OS390 TSM Performance questions.

2003-02-14 09:51:09
Subject: Re: OS390 TSM Performance questions.
From: PAC Brion Arnaud <Arnaud.Brion AT PANALPINA DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 14 Feb 2003 15:46:12 +0100
Richard,

I totally agree with you, but if I tell you that my current situation
happened due to the "help" from IBM support, what would you answer ? I
had a rock solid system running TSM 4.2.2.1, until we had a problem with
a tape library wich was unable to locate some tapes, I was then asked to
update the library microcode, what I did. Off course another problem
appeared, that this time should be corrected by upgradation from TSM
server : I followed IBM expert advices, and this was the beginning of an
upgradation waltz : microcode again, server etc etc ... Until the
current state ! Sorry to tell you that, but I have 3 years of practice
with TSM, and from what I'm seeing since approx 6 month, the product and
service quality is really sinking. Just look at this list : why are so
many people asking what version of TSM they should use ? Response :
because ex-tivoli/IBM is not even able to deliver a non bugged version
of its product. The last time I opened a PMR with IBM, do you know what
their answer was : wait until next M.L. delivery, and jump to Version 5
! Sorry but with such conditions, I can't afford buying another 6H0 and
two 3584 libraries , just to test if "experts" advice would better or
impair my productive environment : I (unfortunately) have to trust them
!
Please, do not consider this as a personal attack, as I consider this
list (and it's eminent members) as the most reliable source of
information concerning TSM, but I'm really bored getting white hair for
problems that would not exist if some people had done their job properly
...
Thanks anyway.

Arnaud (now calmed).

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
| Arnaud Brion, Panalpina Management Ltd., IT Group     |
| Viaduktstrasse 42, P.O. Box, 4002 Basel - Switzerland |
| Phone: +41 61 226 19 78 / Fax: +41 61 226 17 01       | 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=



-----Original Message-----
From: Richard Sims [mailto:rbs AT BU DOT EDU] 
Sent: Friday, 14 February, 2003 14:22
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: OS390 TSM Performance questions.


>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