ADSM-L

Re: Stop Bagging TSM Developers.

2003-02-17 16:00:36
Subject: Re: Stop Bagging TSM Developers.
From: "Hart, Charles" <charles.hart AT MEDTRONIC DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Mon, 17 Feb 2003 14:55:30 -0600
I have had a discussion with a Tivoli - IBM  CE/Sales Rep and he stated that 
IBM appears to be getting the message that many of us want more stability that 
features, which will then dictate how many new versions per year will be 
released.  



-----Original Message-----
From: Mark Bertrand [mailto:Mark.Bertrand AT USUNWIRED DOT COM]
Sent: Monday, February 17, 2003 1:21 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Stop Bagging TSM Developers.


I also agree,

Fix the bugs or extend the support on 4.

Mark B.

-----Original Message-----
From: Rainer Tammer [mailto:tsm AT SPG.SCHULERGROUP DOT COM]
Sent: Monday, February 17, 2003 8:16 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Stop Bagging TSM Developers.


Hello,
I completely agree with Eric.
Fix the bugs in the current level ant delay new functions.
We are on 4.2.1.15 and we want to upgrade to a 5.x level...

Bye
  Rainer Tammer

On Mon, 17 Feb 2003 10:33:43 +0100, Loon, E.J. van - SPLXM wrote:

>Hi Steve!
>I don't understand your message. I haven't read any offending message about
>development on this list.
>Sure, there are several complaints about the stability of TSM lately, but I
>think the people have the right to complain in this case. Lately there have
>been several patches to patch patchlevels (think about the system object
>fixes).
>We all have to upgrade TSM to 5.1.x before April 15th. but we are eagerly
>awaiting a stable PTF level.
>We all know that TSM development are all doing everything they can to fix
>all bugs and we DO appreciate that very much!! But I think I speak for a
lot
>of users when I say that Tivoli should wait with implementing new features
>for a while so they can put all efforts in making the product more bug
free.
>On my part I volunteered for the TSM Beta program to help Tivoli debugging
>this fine piece of software.
>Kindest regards,
>Eric van Loon
>KLM Royal Dutch Airlines
>
>-----Original Message-----
>From: Steve Harris [mailto:Steve_Harris AT HEALTH.QLD.GOV DOT AU]
>Sent: Monday, February 17, 2003 03:29
>To: ADSM-L AT VM.MARIST DOT EDU
>Subject: Stop Bagging TSM Developers.
>
>
>Dear List,
>
>I'm compelled to ask you to please stop bagging the TSM development and
>support folks.
>
>TSM is a very complex product running in very complex environments, no two
>of which are the same. It runs on multiple platforms both client and
server.
>The product has evolved a long way from its origins, as has the computing
>environment in general - I am sure that many of the original assumptions
>that the developers made are no longer valid.  For example, who, ten years
>ago would have thought that a 3TB disk store might be a cheap proposition?
>
>The TSM folks have contantly improved their product in response to user
>input and client OS developments - again some of these changes may well go
>against the philosophy of the product - take windows system objects for an
>instance.  Change = vulnerabilty to error in the short term.
>
>As to support expertise, this is a niche product with few users.  Level one
>and even level 2 folks need  time to become familiar with it and they do
>that the same way as we do, by interacting with the product (or in their
>case with users of the product who have problems).  Would you like to be a
>level 3 expert in TSM who spends your day doing lower expertise support
>tasks?  I don't think so.  And those level three folks are needed to
enhance
>debug and develop the TSM product line.
>
>Finally I need to remind us all that TSM patches are just that, Patches
>designed to fix a particular problem.  Whilst it is sometimes impossible to
>avoid the "upgrade waltz" that someone here has recently mentioned,
>upgrading to a patch level should only be done *if you are affected by the
>problem that the patch addresses*. If you don't have the problem, go to the
>maintenance level, not the latest patch.
>
>Shooting at the development and support folks is easy and feels good in the
>short term for the poster, but it is depressing in the long run for them
and
>for the rest of the list, and, ultimately futile.  I'd ask you all to think
>twice before firing off the next salvo.
>
>Steve Harris
>(Asbestos suit donned!)
>AIX and TSM Admin
>Queensland Health, Brisbane Australia
>
>
>
>**********************************************************************
>This e-mail, including any attachments sent with it, is confidential
>and for the sole use of the intended recipient(s). This confidentiality
>is not waived or lost if you receive it and you are not the intended
>recipient(s), or if it is transmitted/ received in error.
>
>Any unauthorised use, alteration, disclosure, distribution or review
>of this e-mail is prohibited.  It may be subject to a statutory duty of
>confidentiality if it relates to health service matters.
>
>If you are not the intended recipient(s), or if you have received this
>e-mail in error, you are asked to immediately notify the sender by
>telephone or by return e-mail.  You should also delete this e-mail
>message and destroy any hard copies produced.
>**********************************************************************
>
>
>**********************************************************************
>For information, services and offers, please visit our web site:
http://www.klm.com. This e-mail and any attachment may contain confidential
and privileged material intended for
the addressee only. If you are not the addressee, you are notified that no
part of the e-mail or any attachment may be disclosed, copied or
distributed, and that any other action
related to this e-mail or attachment is strictly prohibited, and may be
unlawful. If you have received this e-mail by error, please notify the
sender immediately by return e-mail, and
delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its
subsidiaries and/or its employees shall not be liable for the incorrect or
incomplete transmission of this e-
mail or any attachments, nor responsible for any delay in receipt.
>**********************************************************************
>

<Prev in Thread] Current Thread [Next in Thread>