Thomas,
I hear your frustration, and I am very sorry that you are having these
problems. We are well aware of the issues involving code quality and
support response times, and are continually working on ways to improve in
these areas. I understand that that doesn't do anything for you now, but I
mention it only to point out that we are not oblivious. One thing I can
assure you of with 100% certainty is that you were not lied to with regard
to the APAR match. That is not our policy, and no one I know in support
(including the person working on your PMR) would engage in such conduct.
I am going to forward your note to support management. At the same time,
if you are not already doing so, you should engage your IBM account rep,
as the nature and scope of these issues is beyond our ability to resolve
on this forum.
Regards,
Andy
Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.eyebm DOT com (change eye to i to reply)
The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.
Thomas Denier <Thomas.Denier AT MAIL.TJU DOT EDU>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
01/31/2003 09:51
Please respond to "ADSM: Dist Stor Manager"
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: TSM support issues
We have a 4.2.3.2 TSM server running under OS/390. We expect to add more
TSM clients, and the workloads on two other mainframe applicatios are
increasing. The mainframe is already short of real memory, and is heading
rapidly for shortages of CPU capacity and network bandwidth. One of the
options being discussed is moving the TSM server to AIX. At least one
manager has argued that we should consider migrating to a different
enterprise backup solution. One of his arguments is that we are getting
poor quality code and poor support.
We have been struggling with one or more memory leaks for a couple of
months. Patch level upgrades have improved performance somewhat, but have
not fixed the problem. We are still finding it necessary to restart the
TSM server twice a day to maintain acceptable performance.
Back when we decided to upgrade to the 4.2.3.2 level I went to the
anonymous FTP server and found a text file referring me to the TSM server
README for information on a password protected FTP server. The
information was not in the README file, so I sent out a query on this
list and opened a severity 2 incident with IBM/Tivoli. I started getting
responses from the list in a couple of hours. IBM/Tivoli finally saw fit
to contact me after five days.
We have since opened another serverity 2 incident for the apparent
memory leak. It has typically taken days of repeated calls to get
administrative responses, such as confirmation that dumps were
received. It took weeks to get a substantive technical response.
We were recently told that our symptoms match open APAR PQ69840. I got
a copy of the APAR description. The alleged match is so poor that I
am struggling to convince myself that the claim was a mistake and not
a deliberate lie.
I welcome any suggestions for rebutting the argument that it is time
to look for a product with better code and better support.
|
