must also be among OS/390 releases that are still service supported.

For example, let's assume you have a multisystem configuration that is running OS/390 Releases 5 and 6. Coexistence of OS/390 Release 5 with OS/390 Release 6 would be supported up through March 2001, when OS/390 Release 5 would no longer be supported from a service perspective, and as a result would no longer be supported from a coexistence standpoint after March 2001 (March 2001 is the planned service withdrawal date for OS/390 Release 5 as shown in the above table).

The OS/390 coexistence policy applies to customers with multisystem configurations, but the OS/390 coexistence policy is generally not applicable to customers with single system environments. Customers with single system environments can migrate from any service supported OS/390 release to a subsequent OS/390 release as long as all requisites are satisfied. For example, a customer with a single system configuration can migrate directly from OS/390 Release 2 to OS/390 Release 7.

Note: There is a case where customers with single system configurations need to consider whether compatibility maintenance may be required. Keep in mind that you may be sharing data or data structures (such as user catalogs) as you shift a single image from production to test and back again. In this case, compatibility maintenance may be required. You should always plan to assure a backout path when installing new software, by making sure any service required to support these activities is identified and installed.

Understanding OS/390 Coexistence with MVS

While the primary purpose of this paper is to help customers with multisystem configurations decide what OS/390 release they should be on by January 1, 2000, it also includes information about the coexistence of MVS releases with OS/390 releases. Changes to the OS/390 support for coexistence with MVS releases were announced in August 1998. (4) Customers for whom this may be applicable will want to take these changes into account in their release migration plans.

Currently, OS/390 and supported MVS releases (as shown in Table 2) can coexist in a multisystem configuration. IBM plans to discontinue this support effective with the OS/390 release that will be made generally available in the first half of 2000. Assuming IBM continues with its current 6 month release cycle, this means that, effective with OS/390 Release 9, coexistence of MVS releases with OS/390 releases will no longer be supported in a multisystem configuration.

IBM recommends that if you are currently running:

MVS (or MVS JES) releases along with OS/390 in a multisystem configuration OR MVS (or MVS JES) releases in a multisystem configuration and have not yet yet migrated to OS/390

that you put plans in place to upgrade your MVS systems to OS/390 Release 8 or an earlier release of OS/390. If you are currently running OS/390 with MVS (or MVS JES) in a multisystem configuration, you will want to make sure that the OS/390 Release you migrate the MVS systems to, falls within the four consecutive releases period.

This gives you the maximum flexibility to upgrade your MVS systems to OS/390 in a nondisruptive manner using rolling IPLs. Note that there is a difference between how long IBM will service a release and how long IBM will ensure coexistence within a multisystem configuration. The plan to withdraw the coexistence for supported MVS releases with OS/390 in a multisystem configuration will not affect service support for these MVS releases. Customers with single system environments will continue to be able to receive maintenance for MVS releases until such time that end of service currency has been reached.

The following table shows the MVS releases that can coexist with OS/390 in a multisystem configuration.

This 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, MVS V5 OS/390 Releases 5, 4, 3, MVS V5 OS/390 Releases 5, 4, 2, MVS V5 etc.

Table 2. OS/390 Coexistence with MVS Legend: MVS V5 - includes MVS/ESA SP V5R2.2, MVS/ESA SP V5R2.0, MVS/ESA SP V5R1.0 (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 and MVS Releases that can Coexist with the OS/390 Release Identified in Column 1 R1 March 1996 January 31, 2001 R1, MVS V5 R2 September 1996 January 31, 2001 R2, R1, MVS V5 R3 March 1997 January 31, 2001 R3, R2, R1, MVS V5 R4 September 1997 January 31, 2001 R4, R3, R2, R1, MVS V5 R5 March 1998 March 2001 R5, R4, R3, R2, MVS V5 R6 September 1998 September 2001 R6, R5, R4, R3, R2 (3), MVS V5 R7 March 1999 (1) March 2002 (2) R7, R6, R5, R4, MVS V5 R8 September 1999 (1) September 2002 (2) R8, R7, R6, R5, MVS V5

Note: IBM discontinued service support (and thus coexistence support with OS/390) for MVS/ESA SP V4 effective June 30, 1999. (5)

What Happens If I Upgrade From OS/390 Release 2, 3 or 4 in the Year 2000?

Having reviewed the previous background information, we are now ready to proceed to the important question we originally set out to ask ourselves. That is, if I am a multisystem customer, what release of OS/390 should I be running by January 1, 2000? In the following discussion, we will use projected OS/390 release numbers that follow the 6 month release cycle but that do not represent announced OS/390 releases.

IBM has announced its intention to ship a new release of OS/390 every 6 months. This scenario implies that, on January 1, 2000, the current release of OS/390 would be Release 8. If you try to migrate to the planned current release (Release 8 or higher) from OS/390 Release 2, 3 or 4, you will fall outside the four release OS/390 coexistence period supported. As a result, you will not be able to do rolling IPLs to upgrade to OS/390 Release 8 or higher. It is for this reason that IBM recommends that customers with a multisystem configuration be on OS/390 Release 5 or higher by January 1, 2000.

So now you ask, what are my migration options if it is decided that the Millennium issue is of such difficulty that my installation cannot carry out a further OS/390 migration beyond Release 4 before Year 2000 and, as a result, will be running OS/390 Release 2, 3, or 4 on January 1, 2000? Furthermore, do any of these options allow me to still do rolling IPLs?

The migration options for customers with multisystem configurations who cannot migrate to OS/390 R5 or higher by January 1, 2000 are as follows:

1.Order an earlier intermediate release of OS/390 that is still marketed and that meets the four release OS/390 coexistence policy. Migrate to this intermediate OS/390 release in the Year 2000, followed by a migration to the OS/390 release currently available in the Year 2000 or 2001. 2.Migrate all the images/systems in the multisystem configuration at the same time. 3.Break up the multisystem configuration and migrate the images/systems and then re-establish the multisystem configuration.

Let's explore each of these options in greater detail.

Option 1 (Stepping Stone):

The basic premise behind Option 1 is that you would plan to order an intermediate release of OS/390 as if you were going to install it in the normal way, but would not put that release into production until sometime after January 1, 2000. You would install this intermediate release in the Year 2000 and use it as a "Stepping Stone" to the release of OS/390 available at the time. Clearly, the higher the "Stepping Stone" OS/390 release the better, with the provision that the "Stepping Stone" release must fall within four consecutive OS/390 releases. Depending on what OS/390 release you are coming from, you might need to install two intermediate releases.

Option 1 requires advance planning to make sure that you have ordered the appropriate intermediate releases while they are still available from marketing. Note that, depending on where in the ordering life cycle a particular OS/390 release is, it may not be orderable for delivery as SystemPac, ServerPac, or SoftwareXcel Installation Express (SIE). IBM normally ships only the current release of a product or the last release of an earlier version (for a specified period of time). The most currently available OS/390 release is orderable and available for delivery in a ServerPac, SystemPac, SIE, or CBPDO. In addition, OS/390 Release 3 (as the last release of OS/390 Version 1) is orderable for delivery as a CBPDO customized offering until December 31, 1998. OS/390 Release 3 is no longer orderable for delivery in a ServerPac, SystemPac, or SIE. (6)

Note: Depending on your geography or individual country, it might be possible to order, for a limited time, OS/390 Release 3 for delivery in SystemPac or SIE.

Option 1 also requires work to get the service level of the intermediate release up to a reasonable service level because the release "ages" as a result of not being put into use right away. You will need to order and install preventative maintenance when you start to install the intermediate release. The recommended service approach is to install Recommended Service Upgrades (RSUs) at the "m-2" months currency level along with any HIPER and PE fixes known at the time of the install. For example, if you are installing the intermediate release in March 2000, it is recommended that you include RSU maintenance available thru January 2000. At a minimum, you will want to make sure that HIPER and PE fixes have been installed. For additional information on RSUs and facilities that can make obtaining preventative and corrective service easier, see "Maintenance after Installation" and "Service Distribution".

Additional information about preventative service is available in paper, "OS/390 Maintenance Recommendations for Improved Availability in a Parallel Sysplex Environment". This paper contains information to assist you with planning a preventive process to attain higher availability in a Parallel Sysplex environment. The basic concepts described apply to non-Parallel Sysplex environments, as well. This paper is available on the WEB at the following URL:

http://www.s390.ibm.com/marketing/psos390maint.html

Note: You should be aware that it is important for you to maintain a license for the version of OS/390 you are currently using. This is to enable you to continue to receive service support.

Notice that Option 1:

does not save a significant amount of effort (it only delays the effort until after the year 2000) requires advance planning and action to order any appropriate releases while they are still orderable requires work to get the service level of the intermediate release up to a reasonable level cuts your installation off from taking advantage of enhancements provided in the intermediate release(s) while the intermediate release(s) are shelved

If availability is the utmost consideration for you, however, this option might be the most desirable.

The following examples use the "Stepping Stone" approach and achieve a rolling IPL in each case. The examples assume IBM continues with its present 6 month release cycle:

For a customer with OS/390 Release 4, it would be possible to: order OS/390 Release 7 in 1999 migrate to Release 7 in late 2000 order and migrate to OS/390 Release 10 in early 2001 For a customer with OS/390 Release 3, it would be possible to: order OS/390 Release 6 by March 6, 1999 or during the period in which OS/390 Release 6 is available through the special ordering accommodation (See "Appendix D: OS/390 Version 2 Release 6 Ordering Reintroduction for OS/390 Coexistence" for information on the special Release 6 ordering accommodation) migrate to OS/390 Release 6 in 2000 order OS/390 Release 9 in 2000 migrate to OS/390 Release 9 in early 2001 For a customer with OS/390 Release 2, it would be possible to: order OS/390 Release 6 by March 6, 1999 or during the period in which OS/390 Release 6 is available through the special ordering accommodation (See "Appendix D: OS/390 Version 2 Release 6 Ordering Reintroduction for OS/390 Coexistence" for information on the special Release 6 ordering accommodation) Note: Special provision allows Release 6 to coexist with Release 2. migrate to OS/390 Release 6 in 2000 order OS/390 Release 9 in 2000 migrate to OS/390 Release 9 in early 2001 For a customer with OS/390 Release 1, it would be possible to: order OS/390 Release 3 by December 31, 1998 (OS/390 Release 4 is no longer the currently available release for OS/390 Version 2. As such, OS/390 Release 1 customers need to order and migrate to OS/390 Release 3 as an intermediate release, if OS/390 Release 4 was not ordered while it was available.) order OS/390 Release 6 by March 6, 1999 or during the period in which OS/390 Release 6 is available through the special ordering accommodation (See "Appendix D: OS/390 Version 2 Release 6 Ordering Reintroduction for OS/390 Coexistence" for information on the special Release 6 ordering accommodation) migrate to OS/390 Release 3 and then OS/390 Release 6 in 2000 order OS/390 Release 9 in 2000 migrate to OS/390 Release 9 in early 2001

Note: If you require an intermediate OS/390 release to be used as a "Stepping Stone", it is very important to place your order for the intermediate OS/390 release while it is still orderable.

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

Answers

Little help here? Can you sum it up for us in a nut shell? It seems to say that IBM-type mainframes are more toast than once thought, but I can't be sure. Cory says there are 50,000 of these puppies in the U.S. Have they gone from toast to burnt toast?

-- semper paratus (tinfoil_is@on.sale), August 28, 1999.

Semper:

I think that he is trying to point-out that most people on this forum can't understand the straight technical information that they need to deal with. Probably correct. The importance of this. I don't know. If you assume that it is just a code problem it is important. If not; not!

Best wishes,

-- Z1X4Y7 (Z1X4Y7@aol.com), August 28, 1999.