Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*Controlling\s+nodes\s+\-\s+storage\s+pool\s+migrations\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*Controlling\s+nodes\s+\-\s+storage\s+pool\s+migrations\s*$/: 2 ]

Total 2 documents matching your query.

1. Re: Controlling nodes - storage pool migrations (score: 1): Author: Zlatko Krastev <acit AT ATTGLOBAL DOT NET>; Date: Sat, 8 Nov 2003 22:45:44 +0200; There is no method to convince the TSM server to skip the biggest node (AFAIK). But the workaround is quite straightforward - define separate stgpool for that node and use the existing stgpool for th; /usr/local/webapp/mharc-adsm.org/html/ADSM-L/2003-11/msg00265.html (13,301 bytes)
2. Controlling nodes - storage pool migrations (score: 1): Author: Roy P Costa <roycosta AT US.IBM DOT COM>; Date: Tue, 7 Oct 2003 10:10:04 -0400; We have storage groups set up for various parts of our business, primary pools being to dasd and migrating to tape in an automated Tape Library (ATL). Most of the nodes in the different storage group; /usr/local/webapp/mharc-adsm.org/html/ADSM-L/2003-10/msg00211.html (11,736 bytes)

Current List: 1 - 2
Page: [1]