VSE and VSE/VSAM add support for VERY Large DASD!

In VSE/ESA V2.6, VSE and VSAM add support for VERY large DASD. One of the common problems for some larger VSE shops today is that 1024 I/O devices are supported by a VSE image, and that number may be insufficient given the multi-Terabyte capacity of some modern DASD subsystems.

Previously, VSE/VSAM could not exploit DASD space beyond relative track number 65,535 on any DASD device. This was not a problem for devices defined as type 3390-3, but for 3390-9 devices, only the first 2/3 of the volume (approximately) could be used by VSAM. The remaining disk space could be used for other files, or was wasted.

The typical solution was to define the disks as 3390-3 devices, but this meant that about 3 times the devices were needed to map the disk subsystem's space, thus some users ran into the VSE 1024 device limit.

VSAM's contribution to this problem in VSE/ESA 2.6 is to now support larger DASD devices. VSE support now will permit logical devices with up to 65,536 bytes per track, 65,536 tracks per cylinder, and 65,536 cylinders on the "volume", if and when such devices are made available. Today, this includes full support for VSAM files on whole 3390-9 logical devices, potentially reducing the number of devices needed for DASD by a factor of 3. VSE/VSAM support of these devices is limited to 3390-9 logical devices -- 10018 cylinders of 15 tracks, each of standard 3390 track capacity (roughly 56K bytes per track).

How does this change impact me?

To enable this support, VSAM made some changes that can impact your existing system:

VSAM files and catalogs on these large devices no longer may have the IMBED or REPLICATE options.

I have recommended for years that these options not be used for any files on volumes which are connected via a controller with cache... which includes 3990s, Internal Disk Subsystems on the IBM Multiprise processors, the P/390 and follow-on processor cards, and VSE under VM (which can provide minidisk cache functions). In addition, use of software caching products (e.g. OPTICACHE), and VSAM itself when sufficient index buffers are provided have the same benefits from NOT specifying IMBED or REPLICATE for your files and catalogs. ECKD DASD performance for write-intensive workloads is improved when IMBED is not specified, as well, through exploitation of a hardware optimization called "regular data format."

Some early users of VSE/ESA 2.6 have reported that the new level of VSAM has incompatibilities with backups created by older releases of VSE and VSAM. Although this should be corrected by the time you read this and start your migration to VSE/ESA 2.6 or 2.7, it still seems that the best approach is to avoid this problem by beginning to fix your VSAM DEFINE and reorganization job steps so that NOIMBED is used instead of IMBED for all VSAM objects, and also that NOREPLICATE is specified as well.

For more information about this change, you can review the VSAM changes documented in the IBM VSE/ESA V2.6 Release Guide. This book is available on-line via the IBM VSE/ESA home page's library link.

There are no additional changes related to VSE/VSAM in VSE/ESA 2.7 beyond that which is available in VSE/ESA 2.7, as of this update (April 2003).