"4.2.2.0 is a really bad release to be running but I do not think it is
your
problem.  4.2.2.12 or 4.2.2.13 are pretty good."

One reason why I'm still running 4.1.5.0 is that pretty much every
"x.x.x.0" release of TSM since has had such problems that several forum
participants have warned about its use.

I've been using this software since ADSM V2, and as it "matures" it just
gets scarier.

I understand that a lot of new functionality has been added, and that it is
a complex product.  I also understand that novice users - like I was in the
days of ADSM 2 and 3.1 - can hang themselves with the system.

But 3.1 had problems that corrupted data until the M5 version.  I don't
think IBM *ever* got 3.7 really working right.  TSM 4.1 seems to be OK, but
the horror stories of 4.2 probably comprise 1/4 of this forum's content.
And now tales of 5.1 blowing up appear on this forum seemingly every other
day.

In IBM's VRML notation, the expectation is that any x.x.x.0 is a production
release meaning that it has passed some sufficient level of testing to be
"certified".  Where the "L" field is non-zero, it is a patch - basically a
temporary hack.

In the next month or so I am going to be upgrading my 4.1 system to 5.1(?).
Even if I immediately upgrade to the latest maintenance, patch, hack, etc.,
will  I be placing my data at risk from internal corruption simply due to
poor QA?  My little company has almost 1/2 million dollars invested in TSM
hardware and software.  I'm sure I can get a high-maintenance backup system
that corrupts data for a lot less money than that.

Venting...

Tab Trepagnier
TSM Administrator
Laitram Corporation