1. It’s Time to Migrate to z/OS 1.4!
2. Cheryl Watson’s TUNING Letter 2002, No. 4 Summary
3. Update to TUNING Letter 2002, No. 4
1. It’s Time to Migrate to z/OS 1.4!
Today IBM issued a very exciting announcement, 202-190. This is the standard release announcement of the availability for z/OS 1.4 (September 27, 2002) and a preview of 1.5. But, in addition to the neat enhancements for z/OS, there are some very significant items that make it especially important for you. This announcement really shows that IBM is listening to its customers and the ISVs. For further details on the announcement, check out the Frequently Asked Questions at http://www.ibm.com/zseries/faq/.
There are three very significant additional items in the announcement:
a. The most important, from my point of view, is the availability of bimodal support for z/OS 1.2, 1.3, and 1.4. Bimodal support allows you to IPL in either 31-bit or 64-bit mode when running z/OS on a zSeries machine. As you recall, I’ve been lobbying for this support, so I’m very excited to see it. Prior to this announcement, you could run bimodal only in OS/390 R10 on a zSeries machine; as soon as you went to z/OS, you HAD to run in 64-bit. Most installations today are on OS/390 R10 because they do not want to make an architecture change at the same time they make a hardware or software change. Well, IBM was listening and is providing this bimodal support to reduce that concern. The support is available for a six-month period starting from the time that z/OS is ordered for a zSeries machine. I approve of the six-month limit because otherwise you might not get around to migrating. Keeping support for 31-bit limits IBM development work, and does you no service. IBM strongly recommends that z/OS 1.4 is the place to be for future enhancements, and I agree.
The other limitation to moving to z/OS on a Zseries machine had been the required change to WLC pricing, but that limitation was removed with announcement 202-105 (see our TUNING Letter, 2002, No. 3, pg 44). With support for OS/390 R10 being dropped in December 2004, there’s now no reason to delay. To help the many customers who will be making to move from OS/390 R10 to z/OS 1.4, IBM is providing a customized migration guide specifically for this move. See the migration Web site athttp://www.ibm.com/zseries/zos/installation/zos_migration.html. It couldn’t be easier. Move thee to z/OS 1.4 as soon as you can. It will position you for what’s to come.
b. The second item that’s dear to my heart is the change from a six-month delivery schedule to a yearly delivery. Again, IBM is listening to customers and ISVs who have not been excited with the six-month cycle. Almost everybody is already skipping a release and doing yearly migrations. It’s also been difficult for ISVs to keep their development and release schedules to the six-month cycle. With a yearly release in September, everyone benefits: IBM can do more thorough testing of releases, ISVs can be better prepared for the changes, and customers can count on a release that’s well tested. There will be one exception to this, and that’s z/OS 1.5. Due to previous development schedules and the probability of an upcoming hardware announcement, z/OS 1.5 (which would normally come out in September 2003) will be delayed until 1Q04.
A change to IBM’s support policy will also benefit customers and ISVs: In the past, IBM provided support for a product for three years and a coexistence/migration policy of two years. This will change to be one policy: the support and coexistence/migration support will both be for three years (as long as there are no service exceptions for a release). That’s a win-win proposition!
c. IBM indicated that there will not be a new architectural level set (ALS) for z/OS 1.5. A new architectural level set would mean that the G5/G6 processors and Multiprise processors would no longer be able to run the new release of software. See our article in TUNING Letter 2000, No. 3, page 13 for an explanation of ALS. That means that the earliest possible new ALS would be the 9/04 release, but z/OS 1.5 would still be available for at least three years, until 1Q07, so those machines still have several years of life in them.
You can expect some additions to z/OS 1.4 along the way. A console enhancement is expected before z/OS 1.5, along with some additional functions. IBM is also stating that z/OS 1.4 will be the release that will exploit new zSeries server enhancements.
z/OS 1.4 is the basis for future enhancements and it’s definitely the place to be. Because there are no longer drawbacks of going to z/OS, I highly recommend that you make this move. You can start ordering this on September 13!
2. Cheryl Watson’s TUNING Letter 2002, No. 4 Summary
The forty-four page 2002, No. 4 TUNING Letter was emailed to electronic subscribers on August 9. Print subscribers should receive their issues the week of August 19. You can purchase a printed copy of the current TUNING Letter for $85 at http://www.watsonwalker.com. The following explains what you can find in our latest TUNING Letter.
Under 60 MIPS Mainframe
The most important management news in this issue concerns the availability of some new mainframe options that are under 60+ MIPS. The solutions use emulation software to run z/OS, OS/390, VSE, z/VM, and VM/ESA on Intel-based machines that range from 8 MIPS to over 60 MIPS. The operating systems are supported by IBM, even though they’re not running on IBM mainframes. Hundreds of installations have used these solutions for replacing old hardware, upgrading to new software, developing software, and providing testing sandboxes. The latest news concerns a new machine which competes with the Multiprise H30 and P30. This new four-way machine has about the same cost and performance of the one-way Multiprise, but offers z/OS capable of running in 64-bit mode. This is something that IBM says is NOT coming on the Multiprise. Our article on page 34 describes the newest features of the systems and how people are using them.
User Experiences
Our last issue (No. 3) was well received because we reported many user experiences that weren’t readily available anywhere else. We’re doing the same in this issue. • Do you remember when the size of CPU cache (high speed buffer) entries (256 bytes) became an issue on the z900 machines? If a program modified data and code within 256 bytes of each other frequently, the performance of the program could suffer. Solutions are provided by the vendors. A benchmark shown on page 20 shows that a similar but smaller improvement can be realized on the G5/G6 processors. • USS error messages are very difficult to decipher (especially for us old 390 folks!), so we’ve included an article on how to interpret them on page 23. • 64-bit installations are doing quite well, but there are still some problems. See page 29.
Elsewhere in This Issue
You will need to change WLM goal velocities when you migrate to z/OS 1.2+. We show on page 41 how to re-calculate those velocities. (The WLM algorithm was changed, but few people noticed the change.) If you go to z/OS 1.3, you’ll automatically get access to some wonderful new data: an SMF record with the identity of who deleted a PDS or PDSE member and when they deleted it (see page 7). Our news section starting on page 4 also includes information on VSAM and catalogs, an HTTP APAR, new tape support, new WebSphere Application Server 4.0.1 features, WLM APARs, how to avoid duplicate USS UIDs and GIDs with a RACF SPE, and Hiper APARs of interest. In Tidbits from the Forums (page 12), we include some z/OS APARs, RACF performance tips, a VSAM corruption APAR, and a lingering Y2K bug. The WSC News highlights several important flashes and some excellent white papers.
3. Update to TUNING Letter 2002, No. 4
On page 30, I introduced APAR OW54938, but then provided the APAR description of OW54938, which had been discussed on page 12. The title of APAR OW54398 should have been: IAXUA LOOPS UNNECESSARILY CALLING IARUVUNC WHEN RCEAFC = 0, HIPER PERFORMANCE, CLOSED (without APARs yet) on 8/12/02 for OS/390 R10+. The description includes the following: “Potential performance degradation in Getframe processing when there is no available frame. When there are no available frames to the system (RCEAFC = 0), IARUALF unnecessarily calls IARUVUNC for each frame in the system. It should do some preliminary checking of the frame to see if it is a good candidate to steal before calling IARUVUNC.”
Stay tuned!