Hi Lloyd

You've had a couple of suggestions regarding an unload/reload approach. I
agree with Pete and would go the route of shifting hardware resources around
in preference to doing an unload/reload. My experience is they always take
longer than anticipated unless you've previously rehearsed it and already
know how long it will take. There are also the data loss issues Pete raised.

I also think it's a more complex process than moving the disks around; the
disk swapping looks like a lot of steps but is really not as bad as it
seems. Your decision will depend on how familiar you are with using the DST
functions.

Operations Navigator is a great tool (there I said it) for working out the
positions of disks and their serial numbers. I always check the serial
numbers of disks on the disk I pull out - but it's getting damn hard to read
the as the print on the stickers is much smaller these days.

My starting plan for your scenario would be:

- Full system save
- Change the QSTRUPPGM system value to *None
- Put the system in Manual mode
- Power down and restart the system to DST
- End RAID (takes the system from 175gb usable to 210)
- Logically remove 1 X 35 Gb drive; NOT the Load source drive! (Storage: 210
-> 175)
- Power down the system using SST Front panel function option
- Swap the unallocated 35gb drive for a 70 gb drive
- Restart system to DST
- Copy the load source drive to the unallocated drive (Storage: 175 -> 210)
This adds 70gb but removes 35 at the same time, so net change of 35 gb
- Power down the system using SST Front panel function option
- Physically remove load source drive
- Relocate copied 70gb drive to load source slot
- Add another 70gb drive
- Restart System to DST
- Add unconfigured 70gb drive to ASP #1 (Storage: 210 -> 280)
- Logically remove 2 X 35 gb drives (Storage: 280 -> 210)
- Power down the system using SST Front panel function option
- Physically remove 2 X 35 gb drives
- Add another 2 X 70gb Drives
- Restart System to DST
- Add unconfigured 70gb drives to ASP #1 (Storage: 210 -> 350)
- Logically remove final 2 X 35 gb Drives (Storage: 350 -> 280)
- Power down the system using SST Front panel function option
- Physically remove last 2 X 35 gb drives
- Add final 2 X 70gb Drives
- Restart System to DST
- Add unconfigured 70gb drives to ASP #1 (Storage: 280 -> 420)
- Start RAID (Storage: 420 -> 350)
- IPL the system
- Change system value QSTRUPGM to previous value
- End and restart QCTL
- STRASPBAL *CAPACITY

I considered using STRASPBAL to empty one of the 35's in advance but given
the storage constraints you mentioned I think it would hurt as much as help.


Hope this helps

Regards
Evan Harris

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
lgoodbar@xxxxxxxxxxxxxx
Sent: Thursday, 3 July 2008 5:15 a.m.
To: midrange-l@xxxxxxxxxxxx
Subject: DASD swap on 810?

We are in the high 80% range, and I am exploring options to replace the
current drives in our 9406/810. Currently, all 6 slots are occupied with
35GB (model 4326) disk units, under RAID parity protection. I'd like to
replace them with 70GB units.



I know we can break the RAID, offload a drive, and remove for a larger
unit. Can this be done while the system is active (i.e. not restricted
state or DST)? We've done concurrent maintenance for drive replacements,
but am unsure for this type of swap. Obviously we would do a full system
save before and after this operation.



How is the load source handled in this scenario?



Since we have so little free space, we would need to swap one drive,
then another. The third round we should be able to swap two drives, then
two more.



Advice and RTMs appreciated.





Loyd Goodbar

Business Systems

BorgWarner Shared Services

662-473-5713




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.