"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
