At V7R1 and above you do not need downtime to accomplish what you want to
do. I do it all the time.
As Larry pointed out DST has all the tooling you need. It's best as you
indicated to drain the drives first as you indicated you would.
The only reasons to go to restricted state would be to change RAID or move a
load source, neither of which you are doing.
Earlier Kenneth you had expressed concern for having disk units in *SYSBAS
and ones in an iASP on the same RAID set or controlled by the same
controller card. Frankly other than a sense of symmetry I don't see the
concern in doing that. True if you have the appropriate equipment and it's
within reason to configure it with RAID adapters aligning with the ASPs, I
would do it, but I would not spend much money to get that environment set
up. Today's RAID adapters, backplanes and drive units are all robust enough
to not need the separation all that much.
If your mixing SSDs and spinny drives definitely pay more attention to the
configuration and RAID set builds, but for similar sized disk units all
running on a system today without I/O issues, I don't see the need to be
concerned.
--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Graap, Kenneth
Sent: Wednesday, April 15, 2015 10:47 AM
To: Midrange Systems Technical Discussion
Subject: RE: Moving RAID protected DISK from an IASP to a USER ASP
I just did a SSD disk swap, went through a similar process.
Evan, All while the system is up and running, no need to go to DST?
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
As an Amazon Associate we earn from qualifying purchases.