In this issue, I’ll cover the following:
1. Upcoming SHARE Conference
2. OS/390 Coexistence Policy
1. Upcoming SHARE Conference
I’ve been a big SHARE fan for many years now and think it’s some of the finest (and least expensive!) training available today. This next conference focuses on my favorite topics, performance and capacity planning. It’s a conference that you won’t want to miss. At $795 (prepaid and postmarked by August 2) it’s a real bargain. Here’s a description from SHARE:
“Benefit from more than 80 sessions dedicated to capacity planning and performance management at SHARE in Chicago, August 22-27. This week-long series of in-depth technical sessions features user success stories, perspectives on different operating systems and vendor tools, and opening and closing keynote presentations by Cheryl Watson of Watson & Walker. For a full session agenda, visit http://www.share.org/capacity.
“SHARE is the premier user-run provider of quality education and networking for technology professionals. SHARE in Chicago features more than 900 technical sessions on an array of enterprise computing topics, including: OS/390, networking, Java, Windows 2000, application development and enablement, CICS, Lotus Notes R5, Y2K readiness, and more.
“The event’s expansive program, knowledgeable attendee base, and affordable registration rate make SHARE in Chicago an unbeatable training experience. Advance registration discounts are available until August 2, 1999.
“For full event information, including online registration and housing information, visit the SHARE Web site at http://www.share.org. Questions? Contact SHARE at (888)574-2735.”
2. OS/390 Coexistence Policy
Does the coexistence policy of N-3 releases apply to single systems?
I have talked to several customers who were told that they couldn’t migrate a SINGLE system from R2 to R7. The coexistence policy definitely states that you CAN make this migration. But like most of the IBMers, I’ve been recommending that single system sites follow the same recommendations as those recommended for multisystem sites. See my notes on the coexistence policy in Cheryl’s Lists #20, 21, and 24.http://www.watsonwalker.com/archives.html
Here is the current wording from IBM’s coexistence policy that can be found at http://www.s390.ibm.com/stories/year2000/coexist.html:
——– Extract ————-
“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.”
———End of extract————-
I asked Greg Daynes from IBM’s OS/390 System Build and Installation team to address this issue. Greg’s reply:
“You are not alone in your confusion about single system migration. As you point out, our coexistence policy applies to multisystem configuration that share resources. This includes:
single processor running multiple LPARs
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)
“We also allow customers in single system environments migrate directly to any given release.
“Let me try and clarify some of the areas of confusion. First, in this context shared resources is any shared data (e.g., CF structures, control blocks, data sets or files) that is persistent across systems (images). Typically, the shared data is in ‘operational data sets’ (separate from the code), such as catalogs, JES SPOOL , the RACF Data Base, ISPF user edit recovery files, or data passed over communications lines. The coexistence policy ensures that if these persistent structures change format in a new release (e.g. the structure of a catalog entry changes, or new fields are defined in the RACF data base), PTFs will be provided on N-3 releases to support the new format. This allows the new release to be installed in existing configurations with minimal disruption. In fact, customers using a Parallel Sysplex configuration can use rolling IPLs to provide continuous availability to their applications. Sometimes these coexistence PTFs are only needed if a new function is used, other times they are required as soon as the new release is IPLed. To be safe, we state that all coexistence maintenance should be installed on ALL lower level systems prior to bringing up the new release for the first time. Note that there are cases where PTFs are not provided, and our customers are instructed not to use certain functions until all the systems are on the new release (e.g. DASD logger).
“Second, single systems customers, by definition, are not sharing resources concurrently. However, they do need to consider what would happen if they have to back out a release after attempting to migrate to it. Single system customers need to ensure that all the “fallback” maintenance is installed on their lower level system(s) prior to migrating to a new release. Most (hopefully someday soon ALL) fallback maintenance is identified in the OS/390 Planning for Installation manual. Currently, there may be cases where a single system customer migrates to a new release, needs to back out that new release and hits a problem. This could be a result of not having installed the necessary ‘fallback’ maintenance or it could be a new problem. While we don’t expect many new problems, the impact of these problems needs to be understood. Since it is new, it may take some time for resolution, and problem source identification (PSI) may require customer recreation of the problem.
“As a result, I as a conservative installer/migrater, would recommend that ALL customers, even single system customers, stay within the N-3 coexistence policy. This provides a higher level of confidence that the risks associated with migration would be mitigated and that if a problem occurred it could be resolved quickly. Therefore, there is a difference between what is possible to do and what I recommend to do. Part of the discrepancy is because I’m very conservative, and there are some tasks that require careful planning (usually by a HIGHLY skilled system programmer). Since I don’t know the skill level of the single system’s system programmer, I have to recommend the least error-prone approach. As the saying goes, better safe than sorry.
“We have and are continuing to look at the OS/390 coexistence policy. As you are aware, to help customers to the greatest extent possible, we (IBM) have or are in process of providing the following:
‘A special provision that allows OS/390 R2 to coexist with OS/390 R6
(allowing up to five consecutive OS/390 releases to coexist in this case).
Note: This special provision applies only to OS/30 R2 coexisting with
OS/390 R6. This provision does not apply to, nor extend the coexistence
period supported for earlier OS/390 releases (OS/390 R1) or subsequent
OS/390 releases (OS/390 R3 or later).
‘A special accommodation that re-opens ordering for OS/390 R6 from May 18,
1999 to June 30, 2000. We feel confident that this 12 month R6 ordering
window, in conjunction with the provision that allows R2 to coexist with
R6, will provide both R2 and R3 (this includes R4 and R5…Cheryl) multisystem
customers the opportunity to implement both their Y2K plans and take advantage
of the OS/390 coexistence policy. Information on this R6 ordering reactivation
accommodation was added to the coexistence paper on the web on 5/14/1999:
http://www.s390.ibm.com/stories/year2000/coexist.html‘ ”
Thanks so much, Greg. So, officially, for multisystem customers who want the benefit of rolling IPLs, you must stay within N-3 releases. For single system customers you don’t need to stay within N-3 releases, but to play safe it would be wiser to stay within those releases.
I’m still recommending the following:
If you’re at R5 – order R7 now or R8 between 9/99 and 3/00 (you’ll still be able to get R6 up until 6/30/00)
If you’re at R4 – order R7 before 9/99 or order R6 before 6/30/00
If you’re at R2 or R3 – Order R6 before 6/30/00
If you’re at R1 – Plan to bring your sleeping bag into work when you migrate
That’s all for now. Stay tuned!