Bruce,
Having just finished (last two days) an FDRPAS-based migration from 2105
Shark DASD to a new 2107 DS8100 subsystem, I can attest that it was a
relatively painless process. We moved a mix of 380+ 3390-3/3390-9
volumes over about 10 hours (everything but page dataset volumes), and
although it looked like it had some impact on the performance of some
drives during the move, we didn't receive any serious complaints from
users.
We use PAV's on all 3390 devices on both 2105 and 2107, and one of the
reasons we didn't attempt to move COMMON and PLPA page dataset volumes
with FDRPAS was the FDRPAS bucket indicating an exposure to system hangs
when disabling PAV's on Page DS volumes without a z/OS APAR fix in place
(final PTF not yet available last time we looked). Since we planned to
IPL to move these datasets, it made sense to just move all Page data
sets via IPL.
The one drawback of FDRPAS that I hope is resolved before our next
migration (several years away I hope) is the current disabling of PAV
support during the volume migration. I can see why it could be a real
mess to have PAVs dynamically changing during the process, but it seems
like it should be technically feasible to disable dynamic PAVs for the
source device during the migration but allow existing PAVs to remain
functional. We have a number of volumes where cutting back to a single
UCB will guarantee 100% device busy from the production load with
response times soaring to 100 msec to 200 msec or higher. With the
trend toward larger devices with additional PAVs to preserve
performance, I see this as becoming even a more serious issue down the
road. The prospect of cutting a mod-27 with a 10-UCB load down to a
single UCB for migration sounds like an exercise that would look like a
system outage to end users of that device.
Bruce Black wrote:
We are migrating from Amdahl DASD to a Shark (Model 800). No one here
has experience with this. A DBA asked the following questions:
What are the performance differences between volumes defined as MOD-3,
MOD-9, MOD-27?
I presume you are asking this about the Shark. On a gross level, no
difference in performance, the number of cylinders is not relevant to
performance.
there is an issue, of course, if you put a lot more datasets on the
larger disks, if it results in a lot more concurrent I/Os to those
datasets. The Shark will certainly perform much better than the Amdahl,
but putting datasets that used to be on 9 3390-3s to a single -27 and
running all the same applications may result in a bottleneck.
What are the implications of changing a volume to a PAV volume?
PAV is designed to address the bottleneck, by allowing multiple
concurrent I/Os to a single volume. As long as the I/Os are all READs,
or are WRITEs to different datasets (different extents on the volume),
they will be allowed to execute concurrently and give you back the
performance that you used to get on multiple smaller disks. PAV is a
very good thing and has very little downside.
What type datasets/databases, if any, are required to be on their own
volumes?
Anything that is subject to RESERVEs of more that a few moments (such as
JES checkpoint datasets) and some performance sensitive datasets (such
as paging datasets, but PAV improves performance for multiple paging ds
on a single volume).
Now that I have paid my dues by answering your questions, let me put in
a plug for our volume migration software, FDRPAS. FDRPAS can migrate
your volumes non-disruptively, while it is in use. See our web site
below or call and ask for sales.
--
Joel C. Ewing, Fort Smith, AR [EMAIL PROTECTED]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
