On Mon, 12 Apr 2010 08:08:22 -0500, Mark Zelden <mzel...@flash.net> wrote:
>BTW, I'm not sure if I mentioned this last year, but they way we shared >these pools between SMSplexes usually was by having the SMS status >in the "owning" SMSplex as "ENABLE"" and then the volumes "owned" by >the other SMSplex in the shared group set to "DISNEW" and visa versa. A-HA! If you did, I missed it. Do you still update the non-"owning" COMMDS periodically, as you described then? DISNEW would allay my nerves, but our Storage team would have to really be on top things. To Nick Jones: everything Barbara said, and then some. These threads have come up more than once in the last year or two, with many contributors. As long IBM marketing dangles the carrot, coroporate IT will continue to support that, and only that, which is necessary to save $$. "Shamplex" has become part of the nomenclature... As for "where" support to restrict offload locations, this too was proposed by a poster last year, and so well-written that some of us ran to the books to read what we thought we missed! I would definitely make use of the feature. In the meantime, I'm looking into RACF profiles to prevent connectors on non- owning images, which in turn restricts offloads. That will only work so long as I have a RACF database per subplex. I reckon we'd better have SMS sorted out before we start RACF data sharing... Regards, Art Gutowski Ford Motor Company ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
