When a Node is decommissioned we typically
- lock the node
- remove it from the schedules
- A script periodically checks for old file systems (Based on retention)
and identifies file systems ready to be removed
- We remove the expired filesystems (and the last active versions) then
remove the node
I rename them to 'OLD-nodename', and rename them back if necessary (i.e., for
restore). I kill/disable any services that they had that once talked to the
TSM server. That's probably too simple, but you're looking for obviously
distinguishable... :)
-Original Message-
From: ADSM: Dist
Don't forget to REMOVE ADMIN nodename before you DELETE NODE (if you
create admin IDs for your nodes).
--
Mark Stapleton ([EMAIL PROTECTED])
CDW Berbee
System engineer
7145 Boone Avenue North, Suite 140
Brooklyn Park MN 55428-1511
763-592-5963
www.berbee.com
-Original Message-
From:
On Mon, 22 Sep 2008 11:22:57 -0500, Mark Stapleton [EMAIL PROTECTED] said:
Don't forget to REMOVE ADMIN nodename before you DELETE NODE (if
you create admin IDs for your nodes).
It'll do it itself.
- Allen S. Rout
I hope it works for you. We recently upgraded to 5.5.1 server on a z/OS
platform, after which most of our scheduled backups failed, apparently because
of some perceived discrepancy found by reverse lookup.
We added the DNSLOOKUP NO parameter as suggested by IBM support (it is
undocumented for
I create inactive/expired node schedules and associate decommissioned
nodes to that schedule until they're ready for filespace removal and
node removal. The schedule name should imply the node's status for
being associated with that schedule: cl-nosched-old.
I do similar things for those nodes
