| |
Are you running OS/390 V2.6 or V2.7? Do you know
IBM no longer supports these releases?
Are you running OS/390 V2.8 or V2.9? Do you know
they become unsupported within months?
Are you running a G4, G3, or earlier level of
processor? Do you know they cannot run z/OS?
Do you know OS/390 V2.6 or V2.7 coexist only as
high as OS/390 V2.10 or z/OS V1.1? But z/OS V1.1 is no longer
available, so OS/390 V2.10 is your only coexistence option?
Then it's time to plan your path to a supported
operating system, and ultimately, z/OS!
The First Steps.
Once you've decided to upgrade OS/390, several tasks
should get started immediately:
- Determine whether to upgrade to OS/390
V2.10 or z/OS V1.3.
- Construct a project plan.
- Establish the project management
infrastructure.
- Perform a survey of all Third Party
products you run under OS/390.
- After completing steps 1 and 4, order the
necessary software products.
Release Considerations.
- If you’re running a G4-capable processor or
lower, you must either upgrade to OS/390 V2.10, or upgrade your
processor to a G5-capable level before upgrading to z/OS V1.3.
- OS/390 V2.10 is supported "At least until
9/30/2004" and can be ordered until 12/17/2002, while z/OS V1.3
is supported until 03/2005 and can be ordered until 09/2002. For the
most current support dates, see http://www.ibm.com/
servers/eserver/zseries/zos/support/zos_eos_dates.html.
- The highest operating system level that coexists
with OS/390 V2.6 and V2.7 is OS/390 V2.10 or z/OS V1.1 (which can no
longer be ordered). OS/390 V2.8 will coexist with z/OS V1.2, and
OS/390 V2.9 coexists with z/OS V1.3.
- Upgrading to OS/390 V2.10 doesn’t involve an
architecture level change in your processor, while upgrading to z/OS
V1.3 requires you to change to z/Architecture. OS/390 V2.10 supports
both the ESA/390 and the z/Architecture levels, allowing you to first
upgrade the operating system, then the architecture level.
- If you upgrade to OS/390 V2.10, you can then
upgrade to z/OS V1.1 via an Upgrade Feature, which is effectively a
maintenance change. The Upgrade Feature can be ordered until
6/25/2002, and z/OS V1.1 is supported until 03/2004.
- Software costs may increase more by upgrading
directly to z/OS V1.3 than OS/390 V2.10, both for the operating system
and for Third Party products. This is dependent on the licensing
arrangements you've made with your vendors.
- Upgrading to OS/390 V2.10 means another upgrade
will be needed to get to IBM's most current operating system, while
moving directly to z/OS V1.3 (if possible) accomplishes this in a
single step. However, a one-step upgrade encompasses 3 additional
releases (and potentially more Third Party product upgrades), making
it a larger single effort involving more change.
- If a V2.10 upgrade is already underway, it may
make sense to complete the upgrade, then move on to z/OS V1.1, via the
Upgrade Feature, then to z/OS V1.3.
- OS/390 V2.10 has been in the field longer, and
thus is more "well-seasoned" code. This is significantly
mitigated, however, if z/OS V1.3 matches the high quality of the last
several operating systems.
- You may run Third Party products that are not yet
supported under z/OS V1.3, precluding its use.
Start the Project Plan.
While it's too early in the process to develop a
detailed project plan, creating a comprehensive, high-level plan that can
be expanded is possible, and critical. The project plan must be dynamic;
it grows and evolves at least into the testing phase of the upgrade. Start
by identifying whatever high-level tasks you can, assign responsible
individuals to each primary upgrade component, and you'll be amazed at how
quickly the detail blossoms!
A project management tool, with good reporting
facilities, is a must for good project planning. This tool will be at the
center of project management, keeping track of project progress, producing
reports upon which the upgrade can be managed, and serving as a
communication vehicle between all project members. Task characteristics
that need to go into the plan are:
- Task description.
- Responsible individual.
- Identification of pre-requisite, post-requisite
tasks.
- Determination of cornerstone tasks and mandatory
completion dates.
- Task duration/person hours. These items often can
only be crudely estimated, and should include time for the unexpected,
with a clear communication that they're only approximations.
- Footnotes or other additional task information
(such as references to supporting documentation).
Here are some additional items to incorporate into
the initial project so they don't get forgotten:
- Third Party product installations should begin
ASAP; they should be moved to production before the operating system
since they're often pre-requisites, and can comprise half or more of
the total upgrade effort.
- The upgrade should be as "vanilla" as
possible. No unnecessary changes should be made in conjunction with
the upgrade.
- Make sure the plan includes both procedures to
upgrade to the new operating system release, and to fall back to the
old release if there are problems with the new release.
- Assume some things will go wrong and allow time
for that.
- If multiple LPARs will be upgraded, create a high
level task for each system.
- Stage upgrades by system, starting with test and
low impact systems.
- Allow time for project management.
Establish Project Management.
A project plan is only as good as the project
management that implements it. Here are some ideas on how to manage
the upgrade:
- Identify a project manager, who will run status
meetings/conference calls and also have primary responsibility for the
project plan.
- Identify a project secretary, who will keep
minutes of status meetings/calls.
- Identify one or 2 IT or user managers who will
participate in the meeting, communicate progress to the rest of the
business, and communicate applications or user requirements to the
project team. Set up formal communications to the rest of your
organization through these individuals, and use it!
- Set up weekly status meetings/calls, with the
expectation that all project team members will participate unless
excused. During this meeting (1) the
project plan should be reviewed, discussed, and updated from the prior
week, (2) review prior meeting minutes
and follow-ups, and (3) new business.
Survey Third Party Product Vendors.
Each Third Party product vendor should be contacted
to identify what product release/maintenance level is required to run with
either OS/390 V2.10 or z/OS V1.3; necessary upgrades become tasks in the
project plan. Build a spreadsheet with columns such as: (1)
product name, (2) vendor name, (3)
Site ID, (4) vendor phone, (5)
current product level, (6) required product
level, (7) latest product level, and (8)
comments. Columns 1 through 5 can be filled out before contacting vendors.
In addition, IBM maintains Vendor Compatibility pages at http://www.ibm.com/servers/s390/os390/os390vend.html
and http://www.ibm.com/s390/s390da/osnp.html.
Order the Software Products.
As soon as the operating system release and Third
Party products needing upgrades are known, they should be ordered. z/OS
can be ordered with ShopzSeries, at http://www14.software.ibm.com/ShopzSeries.
Installation can begin as soon as the products arrive.
Researching the Upgrade.
IBM Product Information.
One area where research must be performed is OS/390
and/or z/OS. Product changes, removal of function, enhancements, migration
tasks, installation tasks, application and operations impact, and a
variety of other aspects must be researched and understood prior to
undertaking the upgrade. This information should then be folded into the
project plan as tasks.
Listed below is a variety of OS/390 and z/OS
sites/manuals where you can obtain information useful in planning your
migration. They are listed in approximate order of value they provide to
the project planning process:
Internal Information.
Information such as prior OS/390 upgrade plans,
files from past upgrades, installation diaries, old "control"
data sets (containing customized installation jobs, etc.), comments in
JCL, source, etc., and the input of past upgrade participants all provide
invaluable information that should be used in building your project plan.
Also, research your systems. Browse user exit
source, scan through key members of PARMLIB, review Startup Procs and
related JCL, verify data set naming and placement, SMP/E setup, etc.; fold
anything relevant into the plan. The better you know your system, the
better the upgrade will go.
Migration Tasks.
Here's a quick list of the most common upgrade tasks
to add to your project plan:
OS/390 V2.10.
- Review and upgrade SYS1.PARMLIB if not using
concatenated PARMLIB.
- Create MVS working data sets if not using
ServerPac Software Upgrade.
- Visit http://www-1.ibm.com/servers/s390/os390/wizards/ia/iav2r10/
and use the OS/390 Installation Planning Assistant to identify
migration tasks based on your environment and release level.
- Review the JES2, JES3, DFSMS, RACF, Language
Environment, IP, SNA etc. Migration Guides to clarify migration
issues, then add applicable migration tasks to the project plan.
- Apply coexistence maintenance identified in
OS/390 V2.10 Planning for Installation (see above).
- Back up existing systems and determine upgrade
and fallback procedures.
z/OS V1.3.
- Perform all migration tasks that are required for
OS/390 V2.10.
- Verify ARCHLVL 2 in LOADxx is specified or is the
default for the processor.
- Verify or convert expanded storage to central
storage.
- Visit http://www-1.ibm.com/servers/eserver/zseries/zos/wizards/ipw/ipwv1r3/
and use the z/OS Installation Planning Assistant to identify migration
tasks based on your environment and release level.
Installation.
Assuming the prior steps have been thoroughly
performed, you now have a comprehensive project plan for upgrading your
operating system. While a few problems will still arise, completion of the
upgrade at this point becomes a matter of executing your plan. Good luck!
Disclaimer.
The opinions in this article are solely those of the
author, and the information herein is to be taken "as-is".
|
