The example system shows only a limited number of DASD units in each classification. You can, of course, have any number of units in any of the classifications (up to the maximum channel and addressing capabilities of your system). All of the DASD is shared among all of the z/OS® images. Where other sharing arrangements cause differences in the use of commands or in the results obtained, the differences are explained.
The example system uses DFSMSdfp to manage its storage. Figure 1 shows those elements of the system that are essential for using the SMS capability of DFSMSdfp. Storage groups 1 through 4 are the storage that is actually under control of the SMS at this time. The data sets on these volumes are the ones referred to as SMS-managed. Expectations are that some of the DASD volumes shown in both this figure and in Figure 2 will be brought under SMS control as time goes on. This expectation applies only to the level 0 volumes, not to the DFSMShsm-owned volumes.
User groups 1 and 2 (Figure 2) are non-SMS-managed level 0 volumes that DFSMShsm manages and that are reserved for particular groups of data sets. Data sets with particular high-level qualifiers in the data set names are directed to these volumes. Groups of volumes to which data sets are directed by their high-level qualifiers are known as data set pools.
The volume pool (Figure 2) consists of non-SMS-managed volumes that are differentiated on some basis other than that of data set names. Data sets that are assigned to these volumes return to these volumes if they are migrated and recalled.
The DFSMShsm common volumes (Figure 2) are the DFSMShsm-managed volumes that contain non-SMS-managed data sets that do not belong on the volumes in either the user groups or the volume pools.
The unmanaged volumes (Figure 2) are level 0 volumes that are not managed by either SMS or DFSMShsm. DFSMShsm operations can be performed on these volumes, but only by issuing commands. Automatic DFSMShsm operations are not performed on these volumes.