× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Early on we moved from 4GB to 8GB disks.  Later, and after adding
several more arms, we went from 8GB to 17GB.  And added more.  DASD
throughput has been one of our major bottlenecks (CPU & the SPD bus are
the others; RAM has mostly been fine).

On our Dev/DR box we started with 8GB disks but again swapped them for
17s.  Swapped again for 15K BCC disks.  Our CE did a real gig-mig when
we upgraded it from a 720 to an 830 as the load source moved to a new
disk in the new CEC (the 720 frame became a migration tower).

Since 1997, the production system has gone from a 620 uni to a 2-way to
a 730 2-way to a 4-way and, shortly, to an i5 570 which we just ordered.
We keep upgrading to 2-3x the CPWs but each time it gets sucked up by
workload increases within 2 years.  Which, I suppose, is a good thing.
The i5 upgrade is actually a box swap - new serial number.  The only
'upgrade' is the transfer of some LPPs.  The 620 started with 8 disks;
we now have 62 but the i5 will reduce that to 54 (all 15K 70GB disks on
2780 controllers).  With the new box DASD utilization will start under
20% and I have very high expectations on throughput.  BTW, the i5 CEC +
4 0595s (to hold the disks) + HMC w/flat panel + dual-LTO2 tape drives +
external DVD-RAM for 2nd LPAR all fit in one rack.

The Dev/DR box hasn't seen as much action; just from a 720 uni to a
2-way 830.  Hopefully I can take it to an equivalent-capable (via CUoD)
i5 next year.

John A. Jones, CISSP
Americas Information Security Officer
Jones Lang LaSalle, Inc.
V: +1-630-455-2787  F: +1-312-601-1782
john.jones@xxxxxxxxxx

-----Original Message-----
From: Chuck Lewis [mailto:clewis@xxxxxxxxxx] 
Sent: Wednesday, November 17, 2004 9:28 AM
To: 'Midrange Systems Technical Discussion'
Subject: RE: How to perform a GIG MIG

Wow - 4 or 5 times in the last two years. Things sure aren't boring for
YOU John :-)

Chuck

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jones, John (US)
Sent: Wednesday, November 17, 2004 9:36 AM
To: Midrange Systems Technical Discussion
Subject: RE: How to perform a GIG MIG

When we've replaced all the disks at once, we essentially did the
backup-replace drives-restore routine.  Everything I've heard says that
a re-load not only distributes your data in the most efficient manner,
but will be faster than removing disks from the config.  You also end up
with a known good system save or two.  Our process is:

1. Make 2 GO SAVE/21s (I guess we're paranoid).  We clean the tape drive
before the first save and use new tapes only.
2. Remove any optical media from the CD drives.
3. Power down & remove all disks being replaced.  Note that (at least on
7xx and newer) you should't need to note the exact location the old
drives were in.  They only need to be attached to the same controller
card; the exact disk slot doesn't matter beyond that.
3. Install the new drives & IPL from D (alternate load source).  This is
why we remove any optical media: When IPLing from D the system might see
& attempt to IPL off a CD disk before it sees the tape drive.  While
harmess (unless you happen to have the LIC CD loaded), it'll add time to
your IPL).
4. Perform the restore as detailed in the Backup & Recovery manual.
It's procedures will guide you through building the RAID set(s), adding
disks to the ASP, and the restore itself.

Really, all of this, including disk replacement, is in the Backup &
Recovery manual.  Truly the most helpful IBM manual I've ever used.  For
this scenario, I typically will make my saves and then follow the "load
source failed, no RAID enabled" checklist which assumes the load source
has failed and, since no RAID was enabled, the system has to be restored
from backup.

The only downside to most shops is the loss of spool files.  In our shop
reports are converted to PDFs in the IFS so we don't consider SPLFs to
be of value.  If it is an issue for you, you can acquire one of the
inexpensive SPLF save applications.  Or, if you've access to another
box, RMTOUTQ all the SPLFs to that machine, do the upgrade, RMTOUTQ them
back.

I've done this 4 or 5 times over the past few years and have never had a
problem.

John A. Jones, CISSP
Americas Information Security Officer
Jones Lang LaSalle, Inc.
V: +1-630-455-2787  F: +1-312-601-1782
john.jones@xxxxxxxxxx



This email is for the use of the intended recipient(s) only.  If you have 
received this email in error, please notify the sender immediately and then 
delete it.  If you are not the intended recipient, you must not keep, use, 
disclose, copy or distribute this email without the author's prior permission.  
We have taken precautions to minimize the risk of transmitting software 
viruses, but we advise you to carry out your own virus checks on any attachment 
to this message.  We cannot accept liability for any loss or damage caused by 
software viruses.  The information contained in this communication may be 
confidential and may be subject to the attorney-client privilege. If you are 
the intended recipient and you do not wish to receive similar electronic 
messages from us in future then please respond to the sender to this effect.


As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.