DSNTYPE and DATACLAS
DSNTYPE is a bit like DSORG. For example, if you want to create a sequential data set (a flat file), specifying DSNTYPE=BASIC is about the same as saying DSORG=PS. There are additional new values, which allow your data sets to take advantage of new features. You specify DSNTYPE=LIBRARY to get a PDSE, as opposed to specifying DSORG=PO to get the older format of partitioned data set. You can specify DSNTYPE=PDS to get the old format. On newer releases of z/OS you have
DSNTYPE=(LIBRARY,1) and DSNTYPE=(LIBRARY,2) to designate the original version of the PDSE structure, and a newer version.
Other values for DSNTYPE include DSNTYPE=LARGE, which is a sequential file with benefits. As the word implies, the LARGE data set can be bigger than an ordinary sequential data set (you may sometimes see it called DSNLARGE). This means that some software products might not be able to handle the LARGE format – old programs generally need to be modified to allow the larger size. Of course DSNTYPE=LARGE only lets you have bigger data sets, it doesn’t allow bigger individual records. For that you’d need LRECL=X (but discussing LRECL now would be a digression).
DSNTYPE=EXTREQ allows you to specify that your data set must reside in the extended area of an Extended Access Volume (EAV). DSNTYPE=EXTPREF means the data set can reside in the extended area, but it isn’t really a requirement. So, yeah, EXTREQ means extended area required, and EXTPREF means extended area preferred. EAV is a newer much larger disk type, divided into the ordinary area that is laid out like any other similar disk, and the extended area that is laid out differently. As you guess, some software is not able to handle the extended area – some programs need to be modified to handle the modified format of data set labels and in fact the revision of the CCHHR structure (which we will not talk about in this post). On newer releases of z/OS you have DSNTYPE=(EXTREQ,1) and DSNTYPE=(EXTREQ,2) to designate the original version of the extended area disk label, and a newer version. Yes of course you also have
DSNTYPE=(EXTPREF,1) and DSNTYPE=(EXTPREF,2) for the same reason.
There are some restrictions on the types of data sets that can reside in the extended area. This will also depend on the level of your z/OS system, with more data set types being supported in newer releases.
Important note: If you want your data set to go in the extended area, you should also specify EATTR=OPT on the same DD statement with DSNTYPE=EXTREQ or EXTPREF (The last time I checked; It seems sort of a superfluous requirement though, and IBM might eventually change things so that the presence of EXTREQ or EXTPREF implies EATTR. EATTR means EXtended ATTRibutes.)
Other values of DSNTYPE include HFS and PIPE. Additional values are certain to be introduced over time.
Why didn’t IBM just replace DSORG with DSNTYPE? Ah come on, when did you ever see IBM replace something and immediately retire the original?
Specifying the DATACLAS parameter in JCL is similar to specifying the LIKE parameter except that with the LIKE parameter you point to a data set to serve as a model, whereas with DATACLAS you specify the name of a class, which is a predefined set of parameter values.
DATACLAS seems to be part of a push by IBM towards making JCL knowledge less of a requirement for ordinary developers and users. By combining a number of parameters into one thing, DATACLAS, the job of writing up the parameters can be done by a systems programmer, a systems administrator, or anyone who can specialize in that area, thus leaving users of the system with less JCL syntax they need to know. It also improves efficiency, accuracy, standardization, and even data security for most data set allocations. And it insulates ordinary users from the need to learn every new JCL parameter or value that IBM needs to introduce.
So, the person responsible for this at your site sets up data classes, assigns them names, and specifies information that might otherwise have needed to be specified in JCL. Better than the LIKE parameter as a simplification. All you need to do is find out the name of the data class they set up for the kind of data set you want to create, and then in your JCL you specify DATACLAS=thatname
For example you might specify DATACLAS=BIGDISK if they used the name BIGDISK to include such parameters as DSNTYPE=EXTPREF – though they probably didn’t pick a name that easy to remember. They can include other parameters like UNIT and SPACE in the class definition, even LRECL and KEYLEN, a bunch of VSAM parameters, and parameters you probably never heard of and don’t care about. (listed at length in the JCL Reference manual).
Leaves you with not much that you’re required to specify in JCL, if the person setting up the data classes has been very thorough. They’re not required to include all the parameters, though, or they can leave them the same as the z/OS system defaults, and that leaves you specifying anythjng you need that they left out. Anyway with exceptions (usually SPACE), most of the parameter values they include in the data class are treated not as limits but as defaults, meaning you can override them in your JCL.
For example, suppose they have set up a data class for you to use for some accounting data files, and they have named the data class ACNTDATA, and all your files in that area have identical characteristics so they have specified everything correctly for you. (Hey, it could happen.) One day you need a data set with a longer than usual record length – maybe the data sets are generally full of records 100 characters in length, but today you got a file from a new customer where they keep extra data security fields at the end of the records, and you need to allow for 200 characters in every record rather than your standard 100.. When you create the new data set for the 200-byte records, put the LRECL override in your JCL
and you will get your 200-byte record size allocated for the data set.
Similarly, if you specify both the DATACLAS and the LIKE parameters on the DD for the same new data set, any attributes obtained from processing the LIKE override any parameters contained in the data class definition for the DATACLAS, unless the data class was set up to prohibit such an override..
Far-fetched Warning Note: SMS must be up and running to make DATACLAS work in your JCL, but it is NOT necessary for your data set to be SMS managed. Notice that SMS is almost always up and running on almost every z/OS site. But if the DATACLAS parameter in your JCL is ignored, that’s what to check – but you won’t be the only one experiencing problems if that happens, the whole system would probably go wonky.
Of course DATACLAS only applies to new data sets, you cannot change a data class for an existing data set by putting a different DATACLAS in your JCL. The DATACLAS you specified would be ignored. Well, the syntax-checking part of the JCL processing would still check for valid syntax, like a security guard in a lobby entrance, but assuming you have it spelled correctly and so on, and parameters are within the valid range of card columns for parameters (starting at or before column 16 if on a continuation card, and extending no further than 71 in any case), there’s no further processing of it. You can still change some individual data set attributes in some cases – either deliberately or accidentally — but not the DATACLAS itself.
So taken on the whole, that should give you some insight into IBM’s apparent strategy of continuing to introduce major upgrades such as allowing bigger data sets and bigger disks, with the JCL parameter changes necessary to support the new features, while at the same time shielding the user somewhat from the disruption of needing to learn a lot of new JCL specifications.
References, further reading.
DSNTYPE parameter in JCL:
DATACLAS parameter in JCL:
How to Set up DATACLAS definitions: