On 1/2/09 11:50 AM, "Harder, Pieter" <[email protected]> wrote:
>> The cost of creating a new set of operational procedures, having your tape >> librarians deal with an additional (and incompatible) set of tape >> technology, > No tape librarians involved. The TSM admin puts new volumes into the libraries > and they stay there forever. OK. If you can afford the hardware and bandwidth, I can see that would work. In the cases I've observed, it's been a case of "either/or" and that the Linux piece (since it's not consistent with the existing TMS-based method on z/OS) tends to be essentially starting from scratch. The tape librarians tend to like "more of the same" solutions where they exist. >> and the TSM on Linux solution uses a lot more people >> resources to manage than the z/OS version. > Why? If the only reason is tape handling then I don't see it. We saved > peoplepower moving from TSM/VM to TSM/Linux. The main reason is that the Linux TSM pieces aren't part of the overall removable media management process that many tape-intensive sites rely on to keep track of data. You're essentially duplicating the tape catalog management, media movement management, and media reliability management in TSM that is a system-wide thing for z/OS. That's always been a annoying thing about distributed systems -- we lose a lot of commonality by allowing every server platform to do it's own thing about data management instead of playing nice with common services. If you have all that stuff automated to a fine point on z/OS, it works out (at least for us) to be cheaper to take advantage of the economies of scale for the greater process (reporting, vaulting, etc) than have each set of server technology reinvent the wheel. YMMV (and obviously it does). ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
