I have discovered that I have not written a tip about how to avoid running out of space on a dataset. It is a very old and known fact that dataset can run out of space. As you probably know a dataset can consist of up to 16 separate blocks of data called extents on the same volume. Because of this many installations have invested in (expensive) software (not delivered by IBM) which almost avoids out of space conditions.
Today you can squeeze vast amounts of data unto a single volume which has made many installations save the costs to the before mentioned software. This does not help a lot if the space parameter in your JCL is specified with a too small secondary allocation. Then you are in deep trouble when all 16 extents has been allocated. Fortunately there exists a little trick that solves the problem. You can just specify the parameter UNIT=(,9). The first subparameter for UNIT can be ignored so you do not need to specify any value for it. The second subparameter specifies how many volumes/units your dataset may span. Using UNIT your dataset is allocated as a multi volume dataset. The neat thing is that a dataset can extent 16 times on each volume so now your dataset can grow much larger.
You can also allocate a multi volume dataset by using VOL=(,,,9). According to the JCL reference you may specify up to 255 like VOL=(,,,255). In the unit parameter 59 is the maximum. And there is one last important detail: only sequential datasets can extent across more than one volume.
I have tested the VOL=(,,,255) and the UNIT=(,59) parameters on the installation where I work. It runs z/OS 2.1 and here I reached a maximum of 59 * 16 = 944 extents. It is the maximum of the UNIT parameter that sets the final limit. There are panels within ISPF where you can specify 16 volume names and on the internet there are discussion claiming a limit of 5 volumes, but 59 seems to be the official limit. There may be differences across different z/OS versions and other limits set on your installation, but 59 is possible in z/OS 2.1.