1. Why Are You Still Running OS/390 R10?
2. z/Architecture Terminology
3. Cheryl Watson’s TUNING Letter 2003, No. 1 Summary
4. TUNING Letter Updates
5. Updates to Our December 2002 CPU Chart
6. New z/OS RSU APAR
1. Why Are You Still Running OS/390 R10?
We were absolutely shocked at SHARE to find that the majority of installations are still running OS/390 R10 in a production environment. We strongly recommend that you migrate to z/OS 1.4 (the latest release) as soon as possible. For over a year, we had recommended that you stay at OS/390 R10 until you could test it on a zSeries machine (because of the lack of bimodal support and the requirement to use IBM Workload License Charges, WLC). This recommendation was first mentioned in our TUNING Letter, 2001, No. 2 (page 31). But IBM announced several significant changes such as the removal of the requirement to use WLC and the support for bimodal support in z/OS 1.4. We announced this in our August 13, 2002 Cheryl’s List #70, when we recommended migrating to z/OS 1.4.
In our opinion, there are no longer any reasons to delay the migration from OS/390 R10. In fact, it’s very important to make the migration as soon as possible. Officially, OS/390 R10 will continue to be supported only through September 2004. IBM lists their end of service dates at: http://www.ibm.com/servers/eserver/zseries/zos/support/zos_eos_dates.html. That leaves you only eighteen months to complete your migration. And if the majority of installations are also delaying, you don’t want to be in line for support as the deadline approaches. Although doing a migration in these times of tight budgets and overworked staff may be painful, the alternative of waiting until the last minute may be even more painful.
The migration from OS/390 R10 to z/OS 1.4 is the most common migration occurring, so it’s a well-tested path. In fact the Migration Guide for this move has just been updated (2/27/03) with feedback from users of the guide: http://www.ibm.com/servers/eserver/zseries/zos. It’s a safe and sane move, so we suggest you start on it soon. For the few installations that have not migrated to WLM goal mode, you’ll need to make that migration first. See our Quickstart policy on our Web site. Speaking of goal mode, z/OS 1.2 goes out of service on 10/04. This is the last release that supports WLM compatibility mode. If you want a supported operating system, you’ll need to migrate to goal mode within 19 months.
As soon as you’re running in production on z/OS 1.4, you should also take the time to investigate WLC pricing. Some installations can save a great deal of money using WLC, although others find that PSLC pricing stills works best. IBM states that 40% of eligible WLC installations are using WLC pricing. You won’t know if WLC works for you until you perform your own analysis, and it isn’t a trivial task. We discuss this in several TUNING Letters: 2000, No. 5; 2001, No. 1; 2001, No. 3; 2001, No. 4 (primary article); and 2002, No. 3.
When you migrate to z/OS on a zSeries machine, you should also investigate whether you can use any of the new facilities now provided in the four z/OS releases. The availability of these new features may even help justify your migration. Many of these features require z/Architecture (marked with an asterisk):
- DB2 Universal Database Server for OS/390 new features (DB2 V8 actually requires z/Architecture) *
- IMS performance enhancements *
- Hierarchical File System (HFS) enhancements *
- Virtual Storage Access Method ( VSAM) enhancements *
- Remote Dual Copy (XRC) enhancements *
- Tape and DASD access method enhancements *
- IRD (It can manage your LPARs much more efficiently that you can – one site reports they were able to get 10% of their machine back with IRD) *
- HiperSockets which can improve TCP/IP throughput and security significantly *
- TCP/IP providing support for IPv6 (new internet addressing standard)
- CF performance enhancements
- Dynamic PAVs (Parallel Access Volumes)
- Report class enhancements
- WLM Enhanced Batch Workload Initiator Balancing
2. z/Architecture Terminology
Mary Beth Bradley, IBM z/OS, mentioned at SHARE that several installations were confused about the term ’64-bit’, and suggested that I might want to clarify things. Thanks, Mary Beth, because we’ve been among the offenders. (Even many IBM documents use ’64-bit’ to refer to ‘z/Architecture’.)
z/Architecture – This is the hardware architecture designed into zSeries machines that supports the following facilities: 64-bit mode addressability (both real and virtual), HiperSockets, Intelligent Resource Director (IRD) and IBM’s License Manager (ILM – which has now been dropped). We discussed z/Architecture in our TUNING Letter, 2000, No. 5. Software, such as z/OS, can exploit each of these hardware facilities. Although z/Architecture and z/VM support expanded storage, z/OS does not. But the z/OS software was changed long ago to support expanded storage facilities (such as hiperspaces) when running in an all central storage configuration.
zSeries – These are the machines that support z/Architecture (as well as the older ESA/390 architecture) and currently include both the z800 and the z900 machines. Notice that the slash used with other “z” terms is NOT used here – it’s zSeries, z800 and z900.
z/OS – This is the operating system that supports the facilities of z/Architecture when run on a zSeries machine. IBM made a change to OS/390 R10 to allow that OS/390 release (only) to exploit 64-bit real.
64-bit (short for 64-bit addressing mode) – This is used to identify one of the three addressing and locatable modes supported by z/Architecture, both real and virtual. 64-bit mode does not need to be used when running z/Architecture, although it’s available both to the operating system and the applications. z/Architecture supports tri-modal (64-bit, 31-bit and 24-bit) operation. Therefore, there are no addressing mode compatibility issues for applications that run in either 24-bit or 31-bit addressing mode when running under z/Architecture.
We have been using the term ’64-bit’ when we should have been referring to z/Architecture. In fact, many of our 64-bit mode articles have more to do with running in a z/Architecture configuration than with 64-bit addressing mode. The majority of the problems we’ve reported occurred primarily because of the elimination of expanded storage rather than anything in the code. We’ll be clearer in our terminology in the future.
The primary message here is that when you migrate to z/OS on a zSeries machine, your applications do not need to be changed, because their 24-bit and 31-bit modes are fully supported. But when you migrate to z/Architecture mode (by installing a new machine or installing z/OS), you should first get very current on maintenance. This is especially true when contacting your ISVs for z/Architecture updates. Also, be sure to ask them about ’64-bit’ updates. The consensus is that you need to contact your ISVs at least twice and talk to different people to get the full story. We’ve talked to several installations who are quite pleased with the performance improvements they have seen when running full z/Architecture mode.
3. Cheryl Watson’s TUNING Letter 2003, No. 1 Summary
The forty-page 2003, No. 1 TUNING Letter was emailed to electronic subscribers on March 7. The print issues will be mailed this week. You can purchase a printed copy of the current TUNING Letter for $95 at http://www.watsonwalker.com. The following shows what you can find in our latest TUNING Letter. It’s taken from our Management Summary.
WLM Goal Mode
Our Focus article in this issue contains several updates on WLM goal mode. Most installations have now either converted to goal mode or are in the middle of migrating to it. As people are learning more about goal mode and how to manage their systems using WLM, more questions are arising. We include some important HIPER APARs and an update on the IEAOPTxx parmlib member (yes, it’s still being used). In fact, a new parameter has just been added for goal mode. An important section of this article is a discussion of WebSphere transactions and how they should be classified in goal mode. This is a very confusing topic and is not well documented in any of the manuals. See page 22 for this Focus article.
Stored Procedures
One of the most important items in this issue is our article on using DB2 stored procedures effectively. DB2 stored procedures were designed for a distributed DB2 complex as a means of reducing the network time and the end-user response time. Used in that manner, stored procedures can provide significant performance improvements. But if they aren’t used for this purpose, the overhead won’t be offset and can be dramatic. See our article on page 26 for a review of the initial design of stored procedures and an example of what can happen if they’re used inappropriately.
Elsewhere in this Issue
The RSU parameter within IEASYSxx defines the amount of reconfigurable storage in an LPAR. It’s been a very confusing parameter, and on page 32 we show how important it is when considering a disaster recovery configuration. * We received great feedback on our MVS Email article from the last issue; page 34 has some reader suggestions. * Media Manager is an access method from IBM that is being used in more products, but little is known about it. Our article on page 34 will give you an overview of this important access method. * Our News section, starting on page 4, provides information on IBMLink, TMON/MVS, some important HIPER APARs, SMF buffers, HFS out-of-space conditions, SAS and hiperspaces, running Java in batch, the OBROWSE command, non-swappable sorts, RACF on z/OS and some important news from IBM’s Washington Systems Center.
4. TUNING Letter Updates
Here’s some new information that came in after we mailed the 2003, No. 1 TUNING Letter:
a. Brian Currah from BDC Computer Services, Inc pointed out that people might be confused about APAR PQ69272 on page 6. It’s an APAR that indicates a pre-allocated file’s DCB characteristics can be changed if opened with DCB information in the JCL. It only applies to Visual Age PL/I – not a large part of the population.
b. In my SHARE ‘Hot Flashes’, I mentioned that APAR OW57718 appeared to be a solution for sort programs (from all vendors) that cause frame shortages. SRM was returning an incorrect value for SYSEVENT STGTEST. In rechecking my emails, I found that the solution has not been successfully tested, although IBM expects it to solve the problem. The APAR is still open. Thanks to John Eatherly from Sprint for pointing this out.
5. Updates to Our December 2002 CPU Chart
a. The STSI model code for the new z900, 2066-0E1, should be ‘0E1’ instead of ‘0A1’. Thanks to Frank Bernhardt of COMPAREX Information Systems.
b. The 9672-Rx4 and 9672-Rx5 machines should have an Architectural Level Set of ‘1’. This was accidentally dropped from the previous CPU Chart.
c. The 2003-102 through 2003-146 models should have an Architectural Level Set of ‘1’. This was incorrectly changed from the previous CPU Chart. This correction was made to the CD-ROM version of the CPU Chart and a correction was sent to electronic subscribers on January 17.
Because these are fairly minor changes, we are not planning to send out update sheets or replacement XLS files. If, however, you’d like the updates, please send an email to Linda May at admin@watsonwalker.com with the subscriber’s name and company name.
6. New z/OS RSU APAR
In TUNING Letter 2003, No. 1 (page 32), we describe reconfigurable storage and recommend the use of RSU=0 in order to avoid certain problems. Brian Currah now tells us about a new related APAR, OA01578, “Flag RCENORCF Incorrectly Set In Z/Architecture Mode.” This APAR relates to z/Architecture (zSeries) and z/OS when RSU=0 and REAL=0 are specified. (We highly recommend these settings, if at all possible.) The APAR documents that a flag is incorrectly set causing transition swaps to be ignored leading to storage fragmentation. This APAR is marked HIPER PERFORMANCE IMPACT. PTFs were issued on 3/5/03 for z/OS 1.2 – 1.4.
Stay tuned!