pg 42-45 7/25/06 10:08 AM Page 1
Administrator
Getting the most from your systems
Avoiding Data-Migration Pitfalls
BY JIM UTSLER
t's a simple fact of life: At some point or other,
I mainframe shops are going to have to migrate or
convert their data. The reasons for this—including
increasing storage capacity or upgrading to new stor-
age devices—vary, but, just as birds fly north or south
depending on the season, there's little escaping it.
Fortunately, data migration doesn't have to cause
migraines for the person in charge. With some careful
planning, the selection of the proper tools and input
from people across the business, obvious pitfalls such
as application downtime and lost data can be
avoided. As Angelo Castellano, systems engineer with
Vienna, Va.-based Softek Storage Solutions, recently
explained to IBM Systems Magazine, Mainframe edi-
tion, a little preparation can go a long way.
Q: Tell us why companies need to migrate or convert
their data. What are some of the reasons behind such
an effort?
A: In days of old, when devices were pretty much the
same, data was moved to do what was called “string
balancing.” Maybe move one volume off of one string
and put it on another string of devices that has less
activity. But, as time went on and device characteris-
tics and track geometries changed, the reasons for
moving data became numerous. Migrations were put
into two categories: one for conversion and the other
for migration. Both require movement, but they're in
actually two separate types of project plans.
In the case of migration, you may have found a
new vendor of choice, and the characteristics or per-
formance specifications of the new devices were better
than the devices that you were currently on. Another
migration type is technology refresh, where the same
vendor is involved, but with newer, more improved,
faster and larger-capacity devices—each with different
characteristics. These two types of migrations are the
front-runners in the data-migration space.
In the case of conversions, the capacity or character-
istics of the target device are additional considerations.
Q: What's the difference between a migration and a
conversion?
42 J U LY / A U G U S T 2 0 0 6 IBM SYSTEMS MAGAZINE
This article is posted with permission from IBM Systems Magazine, Mainframe edition.
A: Well, there are two types of conversions: device
type and device capacity. There are different model
numbers in the industry, each with different track
sizes. For example, a 3380-type device where the size
of the track is 47,000 bytes, and with the 3390-type
device, the track size is 54,000 bytes.
When you're dealing with different device types,
conversions can take place between different track
sizes. This is known as track geometry. Then, there
are conversions of different capacity types. For
example, one device might have 3,000 cylinders and
another device 9,000 cylinders. So, although the track
size is identical in the 3390, a particular model could
be the differentiator. You could have a 3390 Model 3
going to a 3390 Model 9, with the mod 9 having a
larger capacity than the mod 3.
I'd say right now, in 2006, the most common con-
version issue, in conjunction with migration, is to
larger-capacity devices. The trick here is how to get
those devices populated non-disruptively.
Q: Are all data migrations equal?
A: I feel all data migrations are equal, because the
foundation of a successful data migration is a disci-
pline and culture that allows data movement with the
same level of importance across any platform, no
matter the type of data you're talking about.
Is the impact different if there's a problem?
Absolutely. The impact could be different if, let's say,
I wasn't dealing with mission-critical data. On the
other hand, if I were dealing with a high-availability,
money-generating application, the impact would be
entirely different and the recovery scenario would be
entirely different. So I think it's a safe discipline to
treat all data migrations equally.
Q: How should one approach migrations and conver-
sions?
A: First, you should become familiar with the data
you're migrating. And that means becoming familiar
with every aspect of that data: who the data owner is,
what the related applications are and who should be
notified that a data migration will be occurring.
pg 42-45 7/25/06 10:08 AM Page 2
Additionally, you have to ask yourself: What is the access
method? Is it a database? How many volumes are involved in
this configuration of this database? In short, you have to start
by knowing everything surrounding that configuration.
Q: So it sounds like you have to coordinate the migration or
conversion between IT and business users.
A: That's exactly correct. Years ago, the IT organization was
the hub of the wheel. Today, it's very safe to assume that the
business drives technology; technology does not drive busi-
ness. Because of this change in discipline, you should get the
people who own the data involved.
For example, we run our business on what we call a “migra-
tion culture”—a lifestyle of moving data. It's not just a checklist
of what you need to do during the migration or conversion
process, but rather a culture developed around that process.
Q: Once you have the plan in place and you've communicated
with all the different parties, what are some of the pitfalls you
should look for before migrating or converting data?
A: Some people don't really plan properly. You always need to
have a plan B in place, and in some cases, even possibly a plan
C. We recommend you always have checkpoints to make sure
that conversions are going correctly. Then, break the migration
down into smaller activities so as to make it manageable. That
may sound unnecessary, but when you have manageable
migrations and checkpoints to make sure that everything is
going OK, it's a lot easier to fall back in case there's a problem.
Implementing migrations in this manner really pays off dur-
ing large projects. For example, what if you run into a prob-
lem when moving the data and the target devices are all
encountering hardware problems? You have to have a plan in
place that compensates for these types of issues.
In addition, you need to consider the time commitment for
completing the migration. I'll give myself 10 hours for a nine-
hour conversion, which provides an hour leeway. It's a matter of
not only the planning, but also developing a fallback routine.
Another thing that's very important is the pre-migration
audit and a post-migration audit. If I'm moving “X” amount of
files, I want to make sure that when I get to my target I have
the same number. I want to be able to validate my work. So
that pre-migration audit is key.
Q: What mistakes do people make when they're migrating data?
A: The technical aspects of data migrations aren’t the only
things to consider. One of the most common mistakes people
J U LY / A U G U S T 2 0 0 6 IBM SYSTEMS MAGAZINE 43
pg 42-45 7/25/06 10:08 AM Page 3
Administrator
“No matter how much planning you do, someone's always going to
say, ‘I had this file, and it's not here anymore. Was anybody in over
the weekend?’ That's an old cliché that seems to never go away.”
—Angelo Castellano, systems engineer, Softek Storage Solutions
make is not communicating with all of the people involved in
the migration and getting the appropriate migration team
together. I've seen people acting as lone wolves, thinking they
can do something but not realizing there are certain prerequi-
sites associated with an application. For example, they may
have customized applications that require follow-up after data
is moved from point A to point B. You have to know that and
communicate it clearly to all involved parties.
Q: Of course, you also don't want to disrupt the business dur-
ing the migration or conversion process.
A: In today's mainframe environments, the windows of oppor-
tunity have become less and less and less, because the business
drivers for nonstop availability have become more and more
and more.
When I started out in this business, we used to have a preven-
tive maintenance day when we’d actually be able to give up the
system for IBM to come in and do certain types of maintenance.
But as time went on, these necessary windows of maintenance
slowly disappeared. That was our first indication that nondis-
ruptive migrations and conversions had to be a fact of life.
So now we're always working with live data. In the past, I
could call up an application group and tell them they're not
going to be up on Saturday. I could say: “I'm coming in, so
you're not going to have your system from 8 a.m. Saturday, so
don't plan on doing anything and don't send anybody to work
over the weekend.” That's not going to cut it anymore.
Now, the application group tells you that on Saturday,
they're driving money from Asia, so you can't touch a thing.
As a result, all of the rules change. Now instead of me telling
them, they're telling me—thus business drives technology, it’s
not technology driving business.
Q: Which tools or techniques best allow for that type of
migration without disruption?
A: No matter how much planning you do, someone's always
going to say, “I had this file, and it's not here anymore. Was
anybody in over the weekend?” That's an old cliché that seems
to never go away.
So as a smart data migrator, what do I need to do? It's like
going into surgery with the right scalpel and the right equip-
ment. You have to go into a migration or conversion with some-
thing that's easy enough to use for the level of flexibility that’ll
allow you to get your job done. When moving data, I look for a
44 J U LY / A U G U S T 2 0 0 6 IBM SYSTEMS MAGAZINE
single, one-stop-shopping toolkit. My prerequisites are usually
vendor-independent, nondisruptive host-based software. That's
where I start. From there, it has to be something that's fairly
easy to use, which allows me to focus more on planning and
data-integrity maintenance. And then it has to be nondisruptive.
But the categories of nondisruptive software aren’t without a
price. There are two schools of thought regarding this. Do I
want to be able to have a migration run faster and utilize more
resources, or run slower and utilize fewer resources? If I have
the luxury of taking five days, I'd be a fool to do it in only two.
If I move that data in two days and cause application owners a
level of impact because I couldn't throttle back the performance
characteristics of my migration, I might cost an organization a
lot more money than just replacing an entire subsystem.
So in answer to your question, I look for a tool that offers one-
stop shopping, that's host-based and that gives me the flexibility
to move data in a way to best accommodate the applications.
Q: Who should be part of the team involved in the planning
and actual migration or conversion process?
A: I believe you should have a migration manager, an alter-
nate-application coordinator and a security coordinator—as
well as software and hardware coordinators.
If I were doing a major migration, I would ask the hardware
vendor for the target and source-configuration information
that I'm moving data for and, additionally, ask them if they
have spare parts on hand in case there are any problems. We
recommend at least a one-hour turnaround and someone on
site if there are problems.
To properly go the whole distance with data migrations, I
look to involve both internal and external players. Also, there
should be a number where you can call the applications group
to give them an idea of where you stand with the migration.
For example, if I'm running a little late, I may have to tell
someone, “you told me I only had ‘X’ amount of data to move,
when in reality I need another 45 minutes. What can you do
for me?” So there has to be that line of communication and a
status check.
Also, never stand alone when you have to make that deci-
sion to fall back or continue to go forward and ask for addi-
tional time. That could lead to an unplanned outage. This is all
part of the planning process: identifying the right people and
announcing the migration and making it known to the entire
organization.
pg 42-45 7/25/06 10:08 AM Page 4
Q: From a planning perspective, what are the differences that
need to be considered when moving volumes versus datasets?
A: With a volume move, you maintain the unique characteris-
tics of the volume serial number. That's the thing that identi-
fies what the volume is. As long as that volume serial number
remains the same, you never have to go to the catalog or
directory to change the location of the data.
But with most migration tools, you only get one pass. Phase
1 allows you to move the data from one volume to another
with little change. There's nothing wrong with that. If we're
going from a 3390 mod 9 (brand A) to a 3390 mod 9 (brand B),
they're both the same capacity. But, if we're going from a mod
9 to a mod 27, things are different. Now, two-thirds of the tar-
get volume remains unpopulated. I have to move and populate
that volume in conjunction with the appropriate tool command
language (TCL) at the dataset level. There's a caveat here, which
is once I change the location, the source name changes and the
source location changes. I now have to change the catalog.
Q: To sum it up, what are your recommendations when
approaching a migration or conversion?
A: One thing I would start with is taking nothing for granted. I've
seen people go into a migration and say, “it's only five volumes.
I'm going to come in and set it up on Saturday. I don't want to
waste my time during the week on five volumes.” I've seen those
same people there on Monday morning with bloodshot eyes.
Also, respect the data. Learn about the data. Take time out to
speak to the right people, make sure you go through your
change-control process and publicize what you're going to do.
I would definitely take almost a month in advance to plan and
organize before touching and moving someone's data. And I'd
make my migration plan—which takes into consideration pre-
planning, migration staging, and pre- and post-migration vali-
dation—known.
It's largely a matter of keeping people informed, creating the
migration plan, publicizing that plan and letting other people
look at—and hopefully identify—the flaws in it. So it's really
about the plan, the people, the input, the fallback.
Q: So, this is no small undertaking.
A: Definitely not. Anybody who says a migration is a small
undertaking has failed.
Jim Utsler is IBM Systems Magazine
senior writer. He can be reached at
jutsler@msptechmedia.com
J U LY / A U G U S T 2 0 0 6 IBM SYSTEMS MAGAZINE 45