- VSAM structures
- VSAM commands
- Performance tuning
- JCL Buffers
- LSR Buffers
- System Buffers
- VSAM parameters
- IAM, a VSAM alternative
- VSAM Recovery
- VSAM RLS, DFSMStvs
z/OS will normally schedule just one I/O at a time to a dataset, even if that dataset is spread over multiple volumes and PAV aliases are enabled. If a VSAM file is allocated multi-volume as a striped dataset, then concurrent I/O is possible. The data is striped by CI rather than by keyrange, and concurrent I/Os can be scheduled to different CIs. Data striping support is provided for all VSAM file types, including KSDS, ESDS, RRDS, VRRDS, and LDS and is often used to speed up batch sequential access.
Only the data component of a base cluster can be striped and a data set can have a maximum of 16 stripes. Data can be striped over a single volume or a set of volumes, and a stripe on a single volume has a maximum of 123 extents per stripe, while a multi-layered stripe, as a stripe that is allocated on several volumes is called, has a maximum of 255 extents per stripe. Because a striped VSAM data set can have a maximum of 16 stripes, a striped data component can have a maximum of 4080 extents.
Starting in z/OS V1R7, the 255-extent per stripe limit is removed if the extent constraint removal parameter in the data class is set to Y. The default value is N
Striping will only work for VSAM files that are allocated in Extended Format. To do this, the dataset must be SMS managed and be allocated with a dataclass that has a 'Data Set Name Type' of 'EXT'. Striping is not supported for Alternate Indexes. With multi-layered stripes, all the volumes that contain the stripes should have the same speed and type.
You specify that you want striping on a Storage Class. There are two different ways to do this, using Sustained Data Rate (SDR) or Guaranteed Space. In both cases you need an SDR that is greater than 0.
SDR: Don't use Guaranteed space, but within the storage class definition set the 'Sustained Data Rate' parameter to a value that should be a multiple of four. The system assumes that each stripe runs at 4MB/s so it divides that number by four to determine the number of stripes to use. The reason it divides by 4 is for historical reasons based on the speed of spinning 3390 format disks.
For example, if you set SDR to 16, the system allocates 4 stripes and the data will be striped over 4 volumes. However if you load the data set and then run a LISTCAT, the output will only show the HURBA on the first volume. For the other volumes, HURBA=0.
Guaranteed Space: If you set SDR > 0 and set the Guaranteed Space parameter to 'Y' then the system will use as many stripes as the number of volumes or units that you specify in your dataset allocation. VOLUMES(* * * *) or UNIT=(3390,4) should both allocate four stripes. However with Guaranteed Space the VSAM file cannot be muti-layered. GUARANTEED SPACE uses the volume count as the number of stripes, and places these all on one volume. If you have PAV enabled, you will be able to schedule concurrent I/Os to this volume. The volume count can be specified in the data class, or in the JCL and can be a maximum of 16. The JCL parameter takes precedence over the data class.
If you define a storageclass called 'STRIPED', then to allocated a striped file, you either code STORCLAS(STRIPED) in your IDCAMS allocation, or pick a dataset name, so that when the STORCLAS ACS routine is invoked, datasets matching that pattern get the STRIPED storage class. To convert a file to striped, rename the old file and all its components, re-allocate the original file with a STRIPED storage class, then IDCAMS REPRO the data from the old file to the new one.
Every stripe in a striped file can go to 255 extents with 123 extents on a single volume. The maximum number of stripes is 16, so the maximum number of extents is 4080.
A stripe can go multi-volume, but the process is a bit complicated.
The stripes on a file that is allocated with the Gspace method cannot go multi-volume as you cannot specify candidate volumes. If you code VOLUMES(* * * * ) in your allocation you get 4 stripes on one volume.
With an SDR allocated file, if you set SDR to 12, then you get 3 stripes. If you then code VOLUMES(* * * * * *) in your allocation, you get 3 stripes on 3 volumes and three candidate volumes, so when a volume fills up, or the stripe goes to 123 extents, it will extend onto another volume.
The CA size calculation changes for striped files too as the CA size must be a multiple of the strip count. For example, the maximum CA size is 16 tracks as the CA can span onto each stripe.
How can you tell if a file is allocated as striped? Run a LISTCAT against it and look for a STRIPE COUNT parameter. If this is greater than 1 then the file is striped.
Generally speaking, sequential access performance improves as you add more stripes until you reach four stripes. After that it tends to flatten out, so consider 4 stripes to be a limit.
You are best using SMB buffering for striped datasets, as then the system will pick the correct number of buffers. If you can't use SMB, then allocate a larger BUFND value than the default or you won't see much improvement. You will need at least as many data buffers as you have stripes. You can use LSR buffers on striped datasets, but you might not get the full performance improvement. Since DFSMS 1.12, VSAM data striping is also available for RLS buffering mode.
While striping does not benefit datasets read with direct access, you might want to consider it anyway for these files, as they will be accessed sequentially during backup, and maybe for other processing like report generating. However, also be aware that if you use a lot of data striping for batch jobs during prime, online shift this might stress your I/O configuration, and cause problems for other applications.