The first release of VSAM shipped in 1973 and was introduced with the IBM System/370. Prior to VSAM, OS/390 provided a number of evolutionary data access methods with a variety of data formats and organizations, such as BSAM (Basic Sequential Access Method), QSAM (Queued Sequential Access Method), BDAM (Basic Direct Access Method), BISAM (Basic Index Sequential Access Method), and QISAM (Queued Index Sequential Access Method). One of the major objectives of VSAM was to provide a single data format, organization and access functions for data stored on DASD.
VSAM usage increased tremendously with the evolution of database technology systems, transaction processing systems, application development tools, and application products. Since DASD and CPU costs remained relatively high, VSAM design and tuning skills remained a high-priority skill for most companies to maintain within their IT departments. An individual with VSAM tuning skills could minimize the I/O, DASD and CPU resources required to support major IT systems by selecting the optimum VSAM parameters and reorganizing the VSAM file structure at the appropriate time.
With the advent of relational database technology, a new type of VSAM data organization scheme emerged: Linear Data Sets (LDSes). An LDS contains only data that can be accessed as byte-addressable strings in virtual storage. Logical records must be blocked and de-blocked by the application. In an IBM mainframe relational environment, that application is DB2 UDB (Universal Database) for z/OS. Therefore, the skills required to maintain high-quality performing VSAM systems were eliminated by the combination of the growth of relational systems with LDS and the reduction in the cost of DASD and CPU.
Needless to say, many non-relational legacy systems still remain in production today, and even with the current costs of DASD and CPU, the financial benefits of tuning these systems can be significant. It’s important to make wasted CPU cycles available to install newer versions of strategic software products and make more CPU resources available to higher-priority tasks. Let’s take a look at DB2 Version 8, which requires significantly more CPU resources than any previous version of DB2 UDB for z/OS.
How can you take back enough VSAM resources from the total CPU pool by reducing the number of VSAM non-relational I/Os to mitigate DB2 V8’s incremental CPU demand? In other words, how can you improve overall capacity allocations so you can “have your cake and eat it, too”?
Do you have CPU resources sitting idle? Most don’t. Even a less than 10 percent CPU performance regression requires some thought to be placed on the environmental workload. The performance objective of DB2 V8 is less than 10 percent CPU performance regression. For DB2 V8, the typical customer workload regression is expected to be 5 to 10 percent higher CPU on average. The deciding factor is workload. Since there’s a huge variation between the best and worse performance cases, even within the specific categories, we suggest you review the details in the IBM V8 Performance Topics Redbook, SG24-6465. Many companies that need or want to migrate to DB2 V8 because of the advantages to their business may face a short-term financial dilemma. How can they offset the increased demands associated with the additional CPU and DASD resource requirements of DB2 V8 and possibly avoid the dreaded, unplanned machine upgrade cost?
Now, we can’t tune the VSAM LDSes, but as in NASCAR racing, one doesn’t always have to purchase a new engine to derive more power. Simply take a more macro view and tune the major components of the power plant, such as your fuel injector system, to the current conditions to get the additional required power. VSAM can be viewed as the fuel injector to your data center VSAM-based systems such as CICS, IMS, and ISPF/TSO. It can make additional CPU resources available to other subsystems in the z/OS operational environment. The CPU resource dilemma can usually be resolved by tuning your VSAM, IMS, or CICS systems, and performing SQL audits and offloading application development. These performance improvements reduce the frequency of machine upgrades and testing costs, and may eliminate additional software expenditures, and reduce your overall CPU utilization. VSAM tends to sit in the background and just get the job done. It’s the underpinning for IMS, ISPF/TSO, CICS, system data sets, and many third-party application packages. However, many companies don’t provide a separate operational budget to provide the technical skills required to tune and optimize VSAM. This could be because:
- VSAM is spread across the enterprise, making it difficult to pin down what major application or line of business has invested in VSAM.
- There may be few capacity planners.
- Not all VSAM performance tools take advantage of recent VSAM performance enhancements.
Why Migrate to DB2 V8?
IBM DB2 V8 is the largest release of DB2 for MVS. It takes full advantage of the zSeries hardware and exploits the z/OS 64-bit virtual addressing capabilities. It eliminates many old limitations in the definition of DB2 objects, provides multi-row fetch capability, enhances Java and Unicode support, and offers numerous other desirable features. With all these enhancements, it’s no wonder DB2 V8 is the largest release ever and provides users with a substantial performance boost for their applications.