Planning your path from OS/390 to z/OS >>
By Jim Schesvold

  • 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
    • 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 and

    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 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:




    OS/390 V2.10 Announcement


    z/OS V1.3 Announcement


    z/OS, OS/390 mktg., service dates

    Vendor Compatibility Pages

    OS/390 Installation Planning Page


    z/OS Installation Planning Page

    OS/390 V2.10 Planning for Inst.


    z/OS V1.3 Planning for Installation


    OS/390 V2.10 Intro, Release Gde


    z/OS V1.3 Intro, Release Guide


    z/OS V1.3 MVS Migration


    OS/390 V2.10 JES2 Migration


    z/OS V1.3 JES2 Migration


    OS/390 V2.10 JES3 Migration


    z/OS V1.3 JES3 Migration


    OS/390 V2.10 DFSMS Migration


    z/OS V1R3 DFSMS Migration


    OS/390 V2.10 Implementation


    z/OS V1.2 Implementation

    redpieces/pdfs/sg246235.pdf to z/OS

    Migrating to z/OS V1R1


    z/OS Announcement Preview


    z/OS V1.1 User Experiences


    Migrating to z/OS R2, Part 1


    Migrating to z/OS R2, Part 2


    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 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 and use the z/OS Installation Planning Assistant to identify migration tasks based on your environment and release level.


    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!


    The opinions in this article are solely those of the author, and the information herein is to be taken "as-is".