• Please help support our sponsors by considering their products and services.
    Our sponsors enable us to serve you with this high-speed Internet connection and fast webservers you are currently using at ADSM.ORG.
    They support this free flow of information and knowledge exchange service at no cost to you.

    Please welcome our latest sponsor Tectrade . We can show our appreciation by learning more about Tectrade Solutions
  • Community Tip: Please Give Thanks to Those Sharing Their Knowledge.

    If you receive helpful answer on this forum, please show thanks to the poster by clicking "LIKE" link for the answer that you found helpful.

  • Community Tip: Forum Rules (PLEASE CLICK HERE TO READ BEFORE POSTING)

    Click the link above to access ADSM.ORG Acceptable Use Policy and forum rules which should be observed when using this website. Violators may be banned from this website. This notice will disappear after you have made at least 3 posts.

Enhancement to new "decommission" command rejected

marclant

ADSM.ORG Moderator
Joined
Jun 16, 2006
Messages
3,619
Reaction score
580
Points
0
Location
Canada
Website
www-947.ibm.com
What I have recommended at a workaround to others is to create a new domain and set the default management class to what meets their needs (60 days, 6 months, a year, whatever). Then update the node to be in that new domain. When expiration run, all objects not bound to the default management class will now default to the default, since the original management class would not exist. And will expire based on the current retention in that domain. No need to copy the domain with all the management classes and update them all individually.

I tested this, and you can even change the node to a new domain after it's been decommissioned. So if you already have nodes that are decommissioned with retentions that are longer than you wish to keep them now, you can still do it.
 

moon-buddy

ADSM.ORG Moderator
Joined
Aug 24, 2005
Messages
7,032
Reaction score
402
Points
0
Location
Somewhere in the US
What I have recommended at a workaround to others is to create a new domain and set the default management class to what meets their needs (60 days, 6 months, a year, whatever). Then update the node to be in that new domain. When expiration run, all objects not bound to the default management class will now default to the default, since the original management class would not exist. And will expire based on the current retention in that domain. No need to copy the domain with all the management classes and update them all individually.

I tested this, and you can even change the node to a new domain after it's been decommissioned. So if you already have nodes that are decommissioned with retentions that are longer than you wish to keep them now, you can still do it.
It just sucks to know that the Developers does not see this as an opportunity for advancement.

TSM is being slapped left and right as new backup software are getting better than before - some have provisions that outruns TSM capability from a data management perspective like faster DB backups and restores, ease of access to VM Ware vCenter, etc.
 

Advertise at ADSM.ORG

If you are reading this, so are your potential customer. Advertise at ADSM.ORG right now.

UpCloud high performance VPS at $5/month

Get started with $25 in credits on Cloud Servers. You must use link below to receive the credit. Use the promo to get upto 5 month of FREE Linux VPS.

The Spectrum Protect TLA (Three-Letter Acronym): ISP or something else?

  • Every product needs a TLA, Let's call it ISP (IBM Spectrum Protect).

    Votes: 18 18.2%
  • Keep using TSM for Spectrum Protect.

    Votes: 61 61.6%
  • Let's be formal and just say Spectrum Protect

    Votes: 12 12.1%
  • Other (please comement)

    Votes: 8 8.1%

Forum statistics

Threads
31,755
Messages
135,383
Members
21,748
Latest member
fabiont
Top