z/OS V1.7: Expanding The Limits

A hallmark of many recent IBM mainframe software announcements has been the expansion of logical limits, hardware exploitation, and increasing the scale of applications that can efficaciously be executed. zArchitecture expanded the addressing capabilities of z/OS from gigabytes to exobytes. The number of LPARs in a physical processor has continually grown, the number and bandwidth of channels has exploded, storage in cache controllers now rivals or exceeds that of main processors, and overall I/O throughput of a FICON storage subsystem moves at dizzying speeds. z/OS has supported these new capabilities as they have emerged, and IBM subsystems (CICS, DB2, IMS, Websphere, etc.) have evolved to exploit these capabilities. The subsystems themselves have also eased restrictions of internal limits. Perhaps no version of subsystem software has so drastically expanded logical constraints in almost every corner of the product as DB2 Version 8 has; CICS TS Version 3 has among other things removed the 32K COMMAREA restriction and provided 64-bit addressing toleration. As business and information system demands have grown, so have the capabilities of the software that manages and enables these applications. z/OS V1.7 continues this trend with robustness. Here’s a look at the facilities provided in z/OS V1.7 that expand the limits of the zSeries – and its successor, the z9 – environment.

Expanded LPAR Support.

z/OS V1.6 as originally delivered supported between 1 and 24 processors in a single logical partition on z990 servers. z/OS V1.7 extends that support up to 32 processors that can be assigned to a single LPAR on a z990 or z9 processor with good scalability characteristics (based on internal IBM testing and measurements). This support has been retrofitted to z/OS V1.6.

However, if zAAP processors (used for specialized Java processing) are being used in an LPAR, these processors take the place of general-purpose processors, and thus reduce the total number of general-purpose processors available in a specific logical partition.

In addition, it is now possible to define up to a maximum of 60 logical partitions on a single z9-109 processor, and to define up to 15 LPARs for a given Logical Channel Subsystem. This is not due to z/OS V1.7 enhancements, but rather to the hardware, microcode, and other components available in the z9-109.

Multiple Subchannel Set Support.

One of the new features of the z9-109 is multiple subchannel set support. z/OS V1.7 exploits this feature by enabling the use of a second subchannel set. As the number of DASD volumes has increased in large z/OS installations, the existing limit of 64K unit control blocks (UCBs) has posed more and more challenges to more and more z/OS systems. By providing the ability of using a second subchannel set, z/OS has doubled the number of UCBs – or logical DASD and tape devices – that can be used. Specifically, the second subchannel set can be used for defining Parallel Access Volume (PAV) aliases. Thus all addresses on the first subchannel set can be used for real devices. EREP support for the second subchannel set is included.

In this z9 scenario, subchannel set 0 provides 63.75K subchannels, and subchannel set 1 provides 64K minus 1 subchannels. Note that on zSeries and earlier machines, only 63K subchannels are available on set 0: 1,024 subchannels are reserved, so it is only possible to define and use 64,512 (63K) UCBs. The z9-109 only reserves 256 subchannels, freeing an additional 768 subchannels on subchannel set 0 for productive use. 768 3390-sized volumes equals an additional 41 terrabytes of DASD storage. So the z9-109 running z/OS V1.7 increases the number of real devices that can be used on the first subchannel set in addition to providing the second subchannel set for PAV aliases. See for more details.

Lastly, Workload Manager (WLM) supports multiple subchannel sets in z/OS V1.7.

Expanded VSAM and Data Set Limits.

z/OS V1.7 alleviates VSAM and general data set restrictions, and expands capabilities by providing significant extensions in various ways. Sizes are enlarged, counts are increased, logical restrictions are eased in the case of many different facilities. Here’s a quick list of the most significant enhancements:

VSAM RLS 64-bit support. VSAM Resource Level Sharing (RLS) under z/OS V1.7 has been enhanced to enable the use of 64-bit storage for index and data buffers. Prior to this enhancement, buffers had to use 31-bit storage and resided beneath the 2-gigabyte bar. This enhancement parallels DB2 V8’s new 64-bit buffering. With the greater amounts of real memory available on the zSeries and z9 processors, increasing buffers can very positively impact I/O performance. To use 64-bit storage, the data set must in a data class defined as RLS Above The 2-GB Bar, and PARMLIB member IGDSMSxx must specify RlsAboveTheBarMaxPoolsize between 500 megabytes and 2 terabytes. See for more details.

Expansion of VSAM extent specification. The previous limit of 255 extents for a VSAM data set component or stripe has been removed in z/OS V1.7. This enhancement applies to both striped and non-striped data sets, and to SMS data sets. This enhancement applies only to SMS-managed volumes. See for more details.

Large-format sequential data set support. z/OS had previously supported a data set size of greater than 64K tracks for extended-format data sets. In z/OS V1.7, this support has been enhanced to include nonextended-format sequential data sets, assuming those data sets are accessed using QSAM, BSAM, or EXCP access methods. This can reduce the need for multiple-volume data sets. Unlike extended-format data sets, large format data sets do not need to be SMS managed. This support is implemented via a new DSNTYPE=LARGE specification on a DD statement, data class, or dynamic allocation equivalent. Certain restrictions apply unless the BLOCKTOKENSIZE=LARGE is specified on the DCBE macro.

Not only has support for large format data sets been provided in z/OS V1.7, but a wide variety of z/OS facilities already exploit this feature under z/OS V1.7. Included in the list of products/elements that support this feature are ISPF, SADMP, IPCS, AMASPZAP, DFSORT, DFSMSdss, and JES2/JES3 (for the spool). In addition, both JES2 and JES3 have announced their intent to support a new maximum volume size for spool data sets. The intended new maximum size will be implemented via the LARGE operand on the DSNTYPE parameter of the DD statement for the spool, allowing the use of spool data sets up to 65,520 cylinders. Lastly, DFSMShsm and DFSMSrmm now support journal data sets of up to 16,777,215 tracks, reducing the number of CDS backups that are required. Large format data set support is also provided for journal backup and certain temporary data sets. See for more details.

IODF Version 5. Due to a generally expanding need for input and output device definitions in a large zSystem installation, as well as new facilities such as multiple subchannel sets, Parallel Access Volumes, and Virtual Tape Subsystems, the current limitation of 2 Gigabytes for an Input Output Definition File (IODF) is being approached. IODF Version 5 has been re-architected to eliminate the use of individual device definitions and to instead use device groups,. IODF V5 implements a new format for device definitions, using device groups where devices share common traits or characteristics such as device type, control unit attachment, processor(s)/channel subsystems attachment, operating system, and esoterics. Device numbers must be in consecutive sequence. This new format can dramatically reduce the size requirements of an IODF, and expand the number of devices in an IODF. See for more details.

Other expanded/enhanced data set facilities.

  • The limit of DASD-only logstreams on a single system has been raised to 16,384. The current limit is 1,024.
  • The Program Management Binder can now optionally compress program objects contained in PDSEs and such UNIX System Services facilities as the zFS and HFS file systems.
  • Buffers used by the SMF dump program (IFASMFDP) can now be placed above the 16M (that’s right, 16M, not 2G) line.
  • The DFSMShsm Tape Table Of Contents (TTOC) has been expanded to provide enough records to allow the definition and use of over 330,000 data sets per volume. An additional benefit of this enhancement is that it allows for over 1,000,000 data sets per backup or migration tape volume, which new high capacity tape cartridges are capable of
  • z/OS Storage Management is enhanced to conserve real storage below the 16M line, and paging operations during periods of heavy paging are more efficient.
  • Standalone dump I/O buffering is more efficacious, improving the performance of dumping storage and prioritizing what data is dumped.
  • GTF and CTRACE now support VSAM linear data sets, exploiting the performance capabilities inherent in this data set type.
  • The summary dump size has been increased, which enhances first-failure data capture by improving the possibilities of capturing necessary problem resolution data without incurring the performance burden of making a system nondispatchable while a dump is taken.

Hipersockets Support for IPv6.

Hipersockets provides a high performance, high thoughput facility within the Communications Server element of z/OS for TCP/IP processing. IPv6 expands IP addressing capabilities by using 128 bits (rather than 32 bits) for addressing objects within a TCP/IP network. This exponentially increases the number of devices or applications that can be addressed, enabling the proliferation of new TCP/IP users and devices such as cell phones and PDAs. z/OS V1.7 combines these 2 facilities to provide powerful new options for mainframe systems. Hipersockets support for IPv6 enables enhanced stack-to-stack communication between z/OS or LINUX stacks. It expands connectivity alternatives between TCP/IP stacks in a sysplex. Implementing 128-bit addressing within the IP address space provides full compatibility to an IPv6 Hipersockets environment. This support requires the use of a z9-109 processor. See for more details.

Where Can I Learn More?

Here are some references – and hyperlinks to access them via the Internet – which discuss the topics reviewed in this article in more detail. The bookshelves listed provide hyperlinks to all the unlicensed online manuals that are part of the library for that product.

Title / URL
IBM Announcement - Preview: IBM z/OS V1.7 & z/OS.e V1.7: World Class Computing / 205-034 /
IBM Announcement - IBM z/OS V1.7 delivers advances in business resiliency & security / 205-167 /
z/OS V1R7.0 Introduction and Release Guide / GA22-7502 /
z/OS V1R7.0 Overview Bookshelf / GA22-7497 /
z/OS V1R7.0 Planning & Installation Bookshelf / SA22-7830 /
z/OS V1R7.0 MVS Bookshelf / GA22-7479 /
z/OS V1R7.0 JES2 Bookshelf / GA22-7481 /
z/OS V1R7.0 JES3 Bookshelf / GA22-7483 /
z/OS V1R7.0 DFSMS Bookshelf / GC35-0429 /
z/OS V1R7.0 Comm. Server Bookshelf / GC31-8792 /
z/OS Home Page /
z/OS Installation Home Page /
What’s New In z/OS? / SHARE /
MVS SCP Proceedings / SHARE /
Introducing the IBM System z9 109: Processor, Memory and System Structure / SHARE /
Systems Center Hardware Update / SHARE /
Introducing the New Sequential Data Set / SHARE /
What's New in DFSMShsm / SHARE /
DFSMSrmm Boldly Goes Aboard the Enterprise / SHARE /
VSAM Record Level Sharing (RLS) Overview / SHARE /
VSAM Record Level Sharing (RLS) 64-Bit Buffering Enhancement / SHARE /
MVS Storage Management Proceedings / SHARE /
JES2 for z/OS 1.7 Large Spool, NJE over TCP/IP, and Other Features That Did Not Make the Announcement Letters / SHARE /
z/OS V1R7 JES3 New Features / SHARE /
What's New in z/OS Communications Server? / SHARE /

Product Availability, Service, and Compatibility.

While the focus of this article is z/OS V1.7 scalability, there’s another important reason to migrate to Release 7. Many installations still run z/OS V1.4, the last “staging” release that IBM has issued. A staging release is a stable, extended-support release for customers who do not wish to regularly migrate to new releases. But it’s time to seriously consider an upgrade. z/OS V1.7 is the last release to provide coexistence\fallback\migration compatibility with z/OS V1.4. z/OS V1.7 will be supported until 09/2008 (projected), while z/OS V1.4 is supported only until 3/31/2007. Thus, z/OS V1.7 provides 1½ additional years of support. Lastly, it will not be possible to order z/OS V1.7 after September, 2006. z/OS merits serious consideration for implementation. See for more details.

1