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

  • Dataset organisation
  • Record format
  • Record length
  • Space allocation
  • How many volumes it can span over


Accelerate DB2 Write with zHyperWrite and "EADM™ by Improving DB2 Logs Volumes Response Time:

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 would specify are

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

    GFS Advert

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.

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 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 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 files 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.
  2. The Reduce Space % field is used if there is not enough space on a volume to satisfy the request in 5 extents or less. In this case, the space request is reduced by the percentage you select to prevent a space abend. A '0' value means you do not want space allocations reduced.

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 s 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


back to top