Search in

Servers S/390 Solutions Services Products How to Buy Success Stories News Library Site Map

S/390 Worldwide

Planning Guide for Multisystem Customers: OS/390 Coexistence and Planning Considerations Through the Year 2000

Author: Evelyn C. Trotter

OS/390 Product Development IBM Poughkeepsie, NY July 1, 1999

Table of Contents

Notices Trademarks Acknowledgement

Introduction

OS/390 Coexistence and Planning Considerations Through Year 2000

Understanding the OS/390 Coexistence Policy Understanding the Difference Between OS/390 Coexistence and Service Policies Understanding OS/390 Coexistence with MVS What Happens If I Upgrade From OS/390 Release 2, 3 or 4 in the Year 2000? Option 1 (Stepping Stone): Option 2 (Migrate All Systems in a Multisystem Configuration): Option 3 (Break up the Multisystem Configuration):

Conclusion

Appendix A: OS/390 Customer Coexistence Extension

Appendix B: Special Support for OS/390 Coexistence; Ordering Reminder for OS/390 R6 by March 6, 1999

Appendix C: OS/390 Version 2 Release 6 Ordering Update

Appendix D: OS/390 Version 2 Release 6 Ordering Reintroduction for OS/390 Coexistence

Appendix E: OS/390 Coexistence; OS/390 Ordering and Migration Considerations

Appendix F: Additional Sources of Information

Planning and Migration Assistant for OS/390 Year 2000 Offerings Maintenance after Installation Service Distribution OS/390 Planning for Installation

Comments

Fifth Edition, July 1999

This is the fifth edition of this document.

Summary of Changes

Summary of Changes, Fifth Edition

New information:

Added customer memo that describes general ordering and migration considerations for multisystem customers and reminds customers to place orders for the appropriate OS/390 release while that release is still orderable. See "Appendix E: OS/390 Coexistence; OS/390 Ordering and Migration Considerations". Added pointer to paper "OS/390 Maintenance Recommendations for Improved Availability in a Parallel Sysplex Environment" as additional reference material on preventive maintenance.

Changed information:

Included several minor changes in the introductory material to Understanding the OS/390 Coexistence Policy. Changed to use "Release 8 or an earlier release of OS/390" in place of "made generally available no later than second half 1999" in Understanding OS/390 Coexistence with MVS, since Release 8 is now an announced release. For completeness, added that the recommendation described should also be considered by multisystem customers who have not yet migrated their MVS systems to OS/390.

Deleted information:

Removed MVS/ESA SP V4 from list of releases that can coexist with OS/390 as MVS/ESA SP V4 was withdrawn from service June 30, 1999.

Summary of Changes, Fourth Edition

New information:

Added customer memo containing details on OS/390 Version 2 Release 6 ordering accommodation. See "Appendix D: OS/390 Version 2 Release 6 Ordering Reintroduction for OS/390 Coexistence". Added pointer to customer memo containing details on OS/390 Version 2 Release 6 ordering accommodation from the applicable sections in this paper. See "Understanding the OS/390 Coexistence Policy", "Option 1 (Stepping Stone):", and "Appendix C: OS/390 Version 2 Release 6 Ordering Update". Added bullet "What are the benefits of the OS/390 coexistence policy" to the introductory list of topics covered in Understanding the OS/390 Coexistence Policy.

Changed information:

Replaced Note that describes that availability of Enhanced HOLDDATA through other deliverables is planned. In its place, added that Enhanced HOLDDATA is also available with CBPDO orders. See "Maintenance after Installation".

Summary of Changes, Third Edition

New information:

Added information on OS/390 Version 2 Release 6 ordering accommodation. See "Understanding the OS/390 Coexistence Policy", "Option 1 (Stepping Stone):", and "Appendix C: OS/390 Version 2 Release 6 Ordering Update". Added reference numbers for customer memos included in Appendix A and B.

Summary of Changes, Second Edition

New information:

Added definition of coexistence and examples of the types of multisystem configurations where coexistence considerations might apply. See "Understanding the OS/390 Coexistence Policy". Added information on special provision that allows OS/390 Release 2 to coexist with OS/390 Release 6. See "Understanding the OS/390 Coexistence Policy" and "Appendix B: Special Support for OS/390 Coexistence; Ordering Reminder for OS/390 R6 by March 6, 1999".

Changed information:

Changed from use of term "multisystem complex and Parallel Sysplex configurations" to term "multisystem configurations". Changed the OS/390 Release 2 example, provided in the "Stepping Stone" approach, to reflect the special provision. As part of this change, an example for OS/390 Release 3 was added for completeness. An example was also retained to show use of OS/390 Release 3 as a "Stepping Stone". See "Option 1 (Stepping Stone):". Several minor editorial changes were made.

Notices

IBM is providing information in this document to help you understand and address your Year 2000 challenge. IBM does not guarantee your results. You are solely responsible for the planning and implementation of your Year 2000 project.

All statements regarding IBM's future direction and intent are subject to change or withdrawal without notice and represent goals and objectives only.

Trademarks

The following terms are registered trademarks or trademarks of the IBM Corporation in the United States or other countries or both:

CICS DB2 IBM IMS MVS/ESA OS/390 Parallel Sysplex ServicePac SP S/390 VM/ESA VSE/ESA

Acknowledgement

I would like to thank Keith George, IBM United Kingdom, for his contributions toward the development of this paper.

Introduction

This paper is a guide for customers who have multisystem configurations (1) (both Parallel Sysplex. and non-Parallel Sysplex multisystem configurations) and who want to know what OS/390. release(s) they should be running by January 1, 2000.

This paper describes the following topics:

Understanding the OS/390 coexistence policy Understanding the OS/390 coexistence policy with MVS Understanding the difference between OS/390 coexistence and service policies What to consider when planning for release migrations through the Year 2000 and beyond What additional sources of information are available to assist customers with OS/390 release migrations, as well as references to IBM offerings and other sources that can help customers with their Year 2000 projects

Note: In this document, the term coexistence is used in the context of OS/390 releases which can reside on systems/images running in a multisystem configuration. This should not be confused with the term coexistence as used in the context of OS/390 residing on a single system along with VSE/ESA and or VM/ESA. in a logical partition or as a VM Guest.

IBM has announced that OS/390 Release 2 is Year 2000 Ready and ITAA-certified (2) and that OS/390 Release 2 will be service supported until at least January 31, 2001. (3) This paper discusses the proposition that while this is true, most customers with multisystem configurations should plan to be on OS/390 Release 5 or higher by January 1, 2000. Customers with multisystem configurations who cannot be on OS/390 Release 5 or higher, need to develop a plan that enables them to migrate after the Year 2000.

We expect that the cost, operational, and functional benefits of a Parallel Sysplex configuration will mean that many OS/390 customers will be running a Parallel Sysplex configuration, and that most customers will choose to be at OS/390 Release 5 or higher by the Year 2000, due to the additional function and facilities available.

With the problem of support for 4-digit dates and large scale Millennium projects, some customers may be thinking that it is prudent to stabilize on a release, for example, OS/390 Release 4, until after the Year 2000. The purpose of this paper is to point out that this approach presents additional complications later for customers with multisystem configurations. These considerations include:

the potential for not being able to leverage the use of rolling IPLs the effect on application availability greater system programming workloads if you wait too long to upgrade

Customers running a multisystem configuration must very carefully consider a decision not to move beyond OS/390 Release 4 before Year 2000 because of the migration considerations for installing higher releases of OS/390 after the Year 2000.

OS/390 Coexistence and Planning Considerations Through Year 2000

This section describes the following topics:

Understanding the OS/390 coexistence policy Understanding the difference between OS/390 coexistence and service policies Understanding OS/390 coexistence with MVS What happens if I upgrade from OS/390 Release 2, 3 or 4 in the Year 2000?

The first three topics provide you with general background information. The fourth topic "What happens if I upgrade from OS/390 Release 2, 3, or 4 in the Year 2000?" describes options, as well as considerations for each option, when upgrading to a new release of OS/390 that is not within the OS/390 coexistence limit of four consecutive releases.

Understanding the OS/390 Coexistence Policy

Let us begin by covering several basics. This includes:

What is coexistence What are the types of multisystem configurations where coexistence considerations might apply What is the OS/390 coexistence policy What are the benefits of the OS/390 coexistence policy

Coexistence is the ability for two or more systems to share resources at the same time. For example, two JES2 levels could share a spool or two DFSMSdpf levels could share catalogs.

Multisystem configurations involving Parallel Sysplex implementations inherently involve the sharing of resources (i.e., the coupling facility). Therefore coexistence considerations will apply to Parallel Sysplex multisystem configurations. For other types of multisystem configurations (those not involving Parallel Sysplex implementations), it is also possible to have resource sharing. For example, multiple systems can share JES spool, user catalogs, or RACF data bases. In the cases where there is resource sharing, coexistence considerations will also apply.

The following are examples of the types of multisystem configurations in which resource sharing can occur:

A single processor running multiple LPARs A single processor which is time-sliced to run different levels of the system (e.g. during different times of the day) Two or more systems running on separate processors Parallel Sysplex configurations (includes basic sysplex)

Let us now explore in greater depth, the OS/390 coexistence policy.

Before October 1997, OS/390 provided release migration flexibility by allowing three consecutive releases of OS/390 to coexist in a multisystem configuration. As an example, OS/390 Releases 1, 2, and 3 or OS/390 Releases 2, 3, and 4 can coexist in a multisystem configuration.

In October 1997, IBM announced an extension to the coexistence policy for OS/390. This extension allows four consecutive releases of OS/390 to coexist in a multisystem configuration. This change extends the coexistence period from 18 months to a maximum of 2 years based on the current six month release cycle. This extension to the OS/390 coexistence policy applies to OS/390 Version 1 Releases 1 through 3, OS/390 Version 2 Release 4, and future releases of OS/390. See "Appendix A: OS/390 Customer Coexistence Extension" for the full description of this letter.

Special Provision: In February 1999, in a letter to current licensees of OS/390 Version 1, customers were informed of a special coexistence provision. This provision provides additional support to allow OS/390 Release 2 to coexist with OS/390 Release 6 in a multisystem configuration. Prior to this provision, OS/390 Release 2 coexisting with Release 6 was not supported since Release 6 falls outside the four OS/390 release coexistence period allowed. Previously, OS/390 Release 2 was only supported from a coexistence standpoint with OS/390 Releases 3, 4, and 5.

It is important to understand that this special provision applies only to OS/390 Release 2 coexisting with OS/390 Release 6. This provision does not apply to, nor extend the coexistence period supported for earlier OS/390 releases (OS/390 Release 1) or subsequent OS/390 releases (OS/390 Release 3 or later). Support for up to four consecutive OS/390 releases running in a multisystem configuration continues to be the general coexistence policy which applies to OS/390 Release 1, Release 3, and all subsequent OS/390 releases. As such, references in this paper to the OS/390 coexistence policy generally assumes the four release coexistence period. Where appropriate, the special provision is noted. For details on the special coexistence provision, see "Appendix B: Special Support for OS/390 Coexistence; Ordering Reminder for OS/390 R6 by March 6, 1999".

For OS/390 Release 2 customers who wish to take advantage of this special provision, it is important to place your order for Release 6 while it is available. In conjunction with the special coexistence provision, an ordering accommodation for OS/390 Release 6 has been provided. This ordering accommodation provides for an extended ordering period for OS/390 Release 6. For details on the R6 ordering accommodation, see "Appendix D: OS/390 Version 2 Release 6 Ordering Reintroduction for OS/390 Coexistence".

Why do you need to understand the OS/390 coexistence policy if you are a customer with multisystem configurations? The ability for multiple OS/390 releases to coexist within a multisystem configuration, provides migration flexibility by allowing the use of rolling IPLs to migrate to a higher OS/390 release.

You can use rolling IPLs when both of the following are true:

the release you are migrating to, falls within four consecutive releases of the OS/390 releases running on the other systems the appropriate toleration/coexistence maintenance has been installed on the other systems in the multisystem configuration

The use of rolling IPLs allows you to migrate each OS/390 system in a multisystem configuration to a higher OS/390 release, one at a time, while allowing for continuous application availability. Data sharing applications, for example, offer continuous availability in a Parallel Sysplex configuration, by treating each OS/390 system as a resource for processing the workload. This allows OS/390 systems running these applications to be IPLed one at a time, to migrate to a new release of OS/390, while the applications continue to be processed by the other OS/390 systems that support the workload. By leveraging LPAR technology, you can use this technique to upgrade your systems without losing either availability or capacity. This method is often described as the "rolling IPL" method because each system is IPLed in turn.

Even when you are using applications that do not support data sharing, rolling IPLs often make it easier to schedule OS/390 software upgrades. It can be very difficult to schedule a time when all applications running on all the systems in a multisystem configuration can be taken down to allow for a multisystem IPL.

When you upgrade OS/390 releases within the coexistence limit of four consecutive releases, you can use the rolling IPL method to upgrade your OS/390 system software. But when you upgrade to an OS/390 release outside the coexistence limit, you must IPL all the systems in the multisystem configuration at the same time. This is true even of Parallel Sysplex environments, so continuous availability cannot be maintained when you do this.

The use of rolling IPLs not only enables continuous availability from an end-user application point of view; it also eliminates the work associated with migrating all OS/390 systems in a multisystem configuration at the same time. For these reasons, a migration approach using rolling IPLs is often desirable when doing a release to release migration in a multisystem configuration.

Note: It is possible to have a multisystem configuration running a mixed environment, for example, running with all four consecutive OS/390 releases such as OS/390 Releases 3, 4, 5, and 6. However, keep in mind that a mixed environment really should represent a multisystem environment that is in transition, not one that continues to run over time. You should complete the migration as soon as possible.

Understanding the Difference Between OS/390 Coexistence and Service Policies

It is important to understand the difference between how long a release is supported and how long IBM will ensure coexistence within a multisystem configuration. Because this can be a source of confusion for some, we will explore this in greater detail using the following table.

The following table assumes that the OS/390 release shown in column 1 is the highest OS/390 release running in a multisystem configuration. Based on this assumption, column 4 shows the possible releases that can coexist with that OS/390 release. Note that any combination of releases shown in a particular row under column 4 is possible. For example, the following combinations are supported from a coexistence standpoint with OS/390 Release 5:

OS/390 Releases 5, 4, 3, 2 OS/390 Releases 5, 4, 3 OS/390 Releases 5, 4, 2 OS/390 Releases 5, 3 etc.

Table 1. OS/390 Coexistence and Service Support Legend: (1) - projected based on the current 6 month release cycle (2) - projected based on the current OS/390 service policy (3) - coexistence of R2 with R6 is supported as a special provision OS/390 Release General Availability (GA) of OS/390 Release Identified in Column 1 Service Support of OS/390 Release Identified in Column 1 is Available Through OS/390 Releases that can Coexist with the OS/390 Release Identified in Column 1 R1 March 1996 January 31, 2001 R1 R2 September 1996 January 31, 2001 R2, R1 R3 March 1997 January 31, 2001 R3, R2, R1 R4 September 1997 January 31, 2001 R4, R3, R2, R1 R5 March 1998 March 2001 R5, R4, R3, R2 R6 September 1998 September 2001 R6, R5, R4, R3, R2 (3) R7 March 1999 (1) March 2002 (2) R7, R6, R5, R4 R8 September 1999 (1) September 2002 (2) R8, R7, R6, R5

IBM's current service policy is to provide maintenance for each release of OS/390 for three years following its general availability (GA) date. However, in recognition of the workload that customers have ahead of them for Year 2000 readiness, IBM is deviating from this service policy for OS/390 Version 1 Releases 1, 2, and 3, and Version 2 Release 4. These OS/390 releases will be considered current until at least January 31, 2001, with IBM providing maintenance during this period. IBM currently intends to provide at least twelve months notice prior to withdrawal of service for any version or release of OS/390.

As described earlier in "Understanding the OS/390 Coexistence Policy", OS/390 supports the coexistence of four consecutive OS/390 releases. To use rolling IPLs to migrate to a new release, customers with a multisystem configuration need to stay within four consecutive OS/390 releases. An underlying assumption is that the OS/390 releases that are running in a multisystem configuration must

-- Mike Childs (MChilds@hotbot.com), August 28, 1999

Answers

Mike,

If you have a point, please make it, but please spare us the pages and pages of marketing administrivia. This stuff is boring even to many, perhaps most, of those who get paid to read it.

Jerry

-- Jerry B (skeptic76@erols.com), August 28, 1999.

Jerry - You have made precisely the point. This document clearly shows that IBM Mainframes require absurd amounts of tedious reading and efforts to get to anything even approaching readiness.

-- Mike Childs (MChilds@hotbot.com)), August 30, 1999.

Oh, that point!

Let me take a stab at putting that into some perspective. First, let me mention that I have been out of that loop for a few years. I imagine that is has changed in various ways, but that some of the basics remain similar to what I had observed.

What I had observed was that a small percentage of customers of an IBM operating system such as VM, or OS/390 (formerly known as MVS), would commonly strive to stay very up to date with new releases and updates. Most other customers would hang back, and wait for the feedback from the geekvine.

One fringe benefit of this was that most customers did not have to spend the time reading most of the marketing docs.

Also, most of the marketing docs (documents) would be reissued whenever a new release was published, but 90%+ of the docs were repeats from previous releases with just a little bit of new comments. So even those who read them could skip most of what they contained.

Most of the interesting stuff would be picked up on the geekvine.

Hope that helps.

Jerry

-- Jerry B (skeptic76@ereols.com), August 30, 1999.