DFSMS, z/OS System Managed Storage - Data Class

The Dataclass construct defines what a file looks like. The Dataclass ACS routine is invoked first and is always invoked, even if a file is not SMS managed. A non-SMS managed data class will not have a dataclass allocated to it though, it will just be used to pick up allocation parameters. The Dataclass is one of those constructs that can be used very powerfully, or it can be almost ignored. A Dataclass is only ever assigned when a file is created and cannot be changed.
A file is described by its


and that's just flat files. VSAM files have lots of other attributes. It is possible to define a new dataset with a simple allocation like dsn=dataset.name, disp=new,catlg),dataclas=clasname, but if you define a Dataclass for every combinations of these attributes, the list would become difficult to manage. The record length is a good example. You probably have hundreds of different record lengths in your organisation, and you don't want to have to add a dataclass every time someone wants a new one.
A suggestion is to define a dataclass for each common combination of dataset organisation and record format, and let your users specify record length and space. So the combinations you might specify are

PS x x x x x
PO x x x x x
PDSE x x x x x

When the users specify this dataclass in their JCL, they can take the SMS defaults for most of the parameters and just code those that they want to override. JCL definitions will override anything that is defined in the dataclass.
There is an exception to this. Some sites use fixed size allocations to get effective use of volume space. If those allocations are overridden in JCL, then volume space usage suffers. In Z/OS R1V10 you can specify an Override Space parameter in the dataclass definition through ISMF, which means that SMS allocations will override JCL space allocations. You do this on the dataclass ISMF panle by setting 'Override Spaceset' to 'Y', but be aware that if this parameter is set, then space allocation is overridden for nonSMS as well as SMS allocations
You can also enforce the use of System Determined Blocksize, by setting the 'SetSystem Determined Blocksize' to 'Yes'.

Another use of the dataclass is to force a file to go multi-volume. When setting a dataclass up in ISMF, you can specify a number between 1 and 59 in the 'volume count' field. When you allocate a dataset, you tell z/OS how much space you want for the initial allocation or primary, then when the primary space fills up, how big extra secondary chumks of space should be allocated. By default, a VSAM file will look for its primary allocation when it extends to a new volume. If you want it to use the secondary allocation, specify 'SECONDARY' in the 'Additional Volume Amount' Field.

An alternative to avoiding space abends at allocation time is to use Space Constraint Relief (SCR). You initiate this by setting SCR=YES, then updating the two parameter fields that govern how it works.

  1. The Reduce Space % field is used in the single step process; used when allocating a data set that has a volume count of 1, allocating a data set with guaranteed space or extending an existing data set to a new volume. Normally, an allocation must be satisfied within 5 extents, but if Reduce Space is in effect and there is insufficient free space on a volume to fit the normal allocation process, then SMS removes the 5 extent limit, then retry the allocation with the space reduced based on the percentage reduction you specify. A '0' value in the Reduce Space % field means you do not want space allocations reduced.
  2. If the volume count is greater than 1, then SMS will usually use a 2 step process to avoid a space abend on allocation. First, SMS will use a best-fit volume selection method to spread the primary quantity over multiple volumes, up to the value set in the Dynamically Extend Volume Count. If this fails due to space constraints, SMS continues with the best-fit method after reducing the primary quantity and removing the 5-extent limit.
    The Dynamically Extend Volume Count (DEVC) field can be set between 0 and 59 volumes. SMS will always try to extend a dataset on an existing volume, but if there is no space, it will then dynamically allocate another volume, provided the existing volume count does not exceed the DEVC. This is not the same as the volume count above. These volumes are allocated as candidates at dataset allocation time and will show up as Candidate Volumes with a Listcat, SCR volumes are dynamically allocated if required and do not show up with a listcat command.

The Data class ACS routine for SMS managed tape has three attributes:
COMPACTION - should SMS use a hardware compaction algorithms to compact the data on tapes.
MEDIA TYPE - 3490, 3590 etc.
RECORDING TECHNOLOGY - track count or EFMT version.

z/OS V2R2 provided some further enhancements to SMS space constraint relief:
A new parameter in the data class is used to show if space reduction on guaranteed space allocation is permitted or not.
The space reduction function is supported on non-striped guaranteed space allocations when allocating a new data set or extending an existing data set to a new volume. However space reduction will not work for striping allocation as the system requires all stripes to have the same space quantity.
SMS will allocate the largest possible space that satisfies the percentage specified in the parameter, Reduce Space Up to (%), during space reduction processing for both guaranteed space and non-guaranteed space allocation requests. If the reduced space is not available on the current volume, the secondary extent is allocated on another volume. For VSAM each extent must be a multiple of the CA size, so the minimum secondary allocation size is always the minimum CA size.
SMS issues a new message to the job log and hardcopy log when the Dynamic Volume Count (DVC) function is invoked

Its probably not worth setting up a dataclass for every variant of VSAM files, but it is a good idea to define some multi-volume dataclasses for VSAM.
Extended format datasets must have a dataclass. They have a COMPACTION attribute which specifies if an extended format dataset should be compressed on disk or not. You create an extended format dataclass by using the parameter DSNTYPE=EXT.

Dataclasses can be used to enforce dataset naming standards. The z/OS dataset types page explains how dataset names are constructed. It is generally accepted that the high level qualifier should be used to describe the application type and these should be quite static as high level qualifiers are used for catalog aliases. The low level, or final qualifier is frequently used to specify what type of management a file will get. It is possible to use the dataclass ACS routine to fail allocations that do not meet standards.

Data classes can be used to assign different values for RLS sharing in Coupling Facility Cache. Options are ALL, NONE, UPDATEONLY and DIRONLY.
DFSMS uses a number of read-only variables, some of which can be set in the Datalas routine, cannot be changed afterwards. These variables can be used later to decide where a dataset is stored, or what kind of management it gets. A new read only variable called &EATTR was introduced with DFSMS 2.1. This is used for extended attribute datasets, datasets that can grow beyond the 65,520 cylinder limit. &EATTR has three options, null, No or OPT. No means extended attributes will not be used and is the default for non-VSAM. The default for VSAM is OPT, which means a dataset has the option to be extended attribute.

Dataclasses can be assigned within your JCL using the DATACLAS= parameter on a DD statement like this


They can also be assigned within IDCAMS ALLOCATE or DEFINE statements like this

  DSNAME(dataset.name) -

Finally, they can be allocated within the DATACLAS ACS routine like this



z/OS Storage and Datasets

Lascon latest major updates

back to top