Bent,

TSM 7.1.1.000 had a bug that sometimes caused restores of large files to fail. 
IBM considered the bug serious enough to warrant removing 7.1.1.000 from its 
software distribution servers.

Thomas Denier
Thomas Jefferson University Hospital

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Bent Christensen
Sent: Saturday, December 06, 2014 6:38 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] SV: TSM level for deduplication

Hi Thomas,

when you are calling 7.1.1- an "utter distaster" when it comes to dedup then 
what issues are you referring to?

I have been using 7.1.1 in a production environment dedupping some 500 TB, 
approx 400 nodes, without any bigger issues for more than a year now.

Surely, there are still lots of "not-very-well-documented features" in TSM 7, 
and I am not at all impressed by IBM support, and especially not DB2 support 
and their lack of willingness to recognize TSM DB2 as being a production 
environment, but when it comes to dedupping it has been smooth sailing for us 
up until now.


 - Bent

________________________________________
Fra: ADSM: Dist Stor Manager [ADSM-L AT VM.MARIST DOT EDU] På vegne af 
Thomas Denier [Thomas.Denier AT JEFFERSON DOT EDU]
Sendt: 5. december 2014 20:56
Til: ADSM-L AT VM.MARIST DOT EDU
Emne: [ADSM-L] TSM level for deduplication

My management is very eager to deploy TSM deduplication in our production 
environment. We have been testing deduplication on a TSM 6.2.5.0 test server, 
but the list of known bugs makes me very uncomfortable about using that level 
for production deployment of deduplication. The same is true of later Version 6 
levels and TSM 7.1.0. TSM 7.1.1.000 was an utter disaster. Is there any 
currently available level in which the deduplication code is really fit for 
production use?

IBM has historically described patch levels as being less thoroughly tested 
than maintenance levels. Because of that I have avoided patch levels unless 
they were the only option for fixing crippling bugs in code we were already 
using.
Is that attitude still warranted? In particular, is that attitude warranted for 
TSM 7.1.1.100?

Has IBM dropped any hints about the likely availability date for TSM 7.1.2.000?

Thomas Denier
Thomas Jefferson University Hospital


The information contained in this transmission contains privileged and 
confidential information. It is intended only for the use of the person named 
above. If you are not the intended recipient, you are hereby notified that any 
review, dissemination, distribution or duplication of this communication is 
strictly prohibited. If you are not the intended recipient, please contact the 
sender by reply email and destroy all copies of the original message.

CAUTION: Intended recipients should NOT use email communication for emergent or 
urgent health care matters.