Sergio, Having developed some of the early training, way before V5, I can tell you that the rationale for platform domains was strictly organizational. In those days, most IT shops were organized by platform and had retention control over their own systems.
Free of the organizational restriction it makes sense to create and populate domains specific to common retention parameters so that you aren't stuck with a lot of include <mgmtclass> statements. ___________________________ Bill Smoldt President www.storserver.com 719-266-8777 x7103 On May 7, 2013, at 1:58 PM, Sergio O. Fuentes <sfuen...@umd.edu> wrote: > Hello all, > > Back in the early TSM 5 days, or at least once when I went to training, it > was advised that each individual platform had its own DOMAIN for retention > and destination control. Now, since I'm evaluating a TSM v6 environment, I'm > rethinking whether that is necessary across the board. Sure, it's advisable > to have platform domains for TDP or NDMP type nodes, because of the way those > platforms handle retention settings for backups. However, have any of you > decided to 'squish' each of the standard OS B/A client domains into one > singular domain? I'm imagining having just one domain for standard B/A > client nodes. (In reality, I'll have many domains for standard B/A client > nodes, but that's for other reasons, i.e. different stgpool hierarchy). > > Is there any reason not to do this? Domain definitions have a default > management class that defines a copy group with retention, destination and > serialization parameters. I can see serialization getting in the way, but > that has only happened ONCE in 8 years of TSM 5. Other domain specific > options like frequency, and mode don't really impact us much. For Windows, > the system state mgmt class is non standard, but since it's not the default, > I don't see why I can't just add it as a non-default Management Class. I'm > already moving away from a directory management class, how about moving away > from the platform-specific domain? > > Thoughts, ideas? Gotchas, that I might be missing? > > As always, thanks, > > Sergio >
