XCOM creates BASIC data set instead of extended format (DSNTYPE)
Article ID: 262544
Updated On:
Products
Issue/Introduction
I want all data sets sent to or received on z/OS to be in extended format. Having my transfers allocate extended format data sets allows me to take advantage of 123 extents per volume rather than the 16 extents allowed for basic or large format data sets. There are other reasons that having extended format data sets (e.g. compression and encryption) that makes allocating extended format useful.
Environment
Release : 12.0
Resolution
For transfers from a non-z/OS system you can define an ACS routine to determine the SMS data class and cause your XCOM data sets to use a data class with DSNTYPE=EXTREQ. The original file transferred from a non-z/OS system will not have a DSNTYPE attribute itself so the ACS routine can set one.
For transfers from a z/OS system the original data set's attribute will be used during allocation (for FILEOPT=CREATE) and overrides the SMS data class setting since a text unit (DALDSNT) is set during allocation to match the source attribute. For a TYPE=SEND transfer you can enable a DEST member that specifies DSNTYPE=EXTREQ in the initiating (source) XCOM. The enabled DEST member will override the DSNTYPE value sent to the partner to specify a value to be used in place of the source data set attribute. The same idea works if the transfer is an execute, TYPE=SEND transfer although specifying the DEST member is done differently with the GROUP= parameter.
For a TYPE=RECEIVE transfer the DEST member DSNTYPE setting isn't being honoured currently. Engineering are planning some changes in this area to allow a DEST member to set a key label (pervasive encryption) in each scenario and will make the change required to get the DSNTYPE to be honoured in the TYPE=RECEIVE scenarios with those changes. Note: With those changes specifying a DSKEYLBL will force EXTREQ since extended format is required.
Additional question:
Will setting LDSNTYPE=EXTREQ in the CONFIG result in all data sets becoming extended format (z/OS and non-z/OS requests)?
No.
For TYPE=RECEIVE transfers, LDSNTYPE can be used to set the default DSNTYPE of the local data set (i.e. the allocated data set that data is received into). LDSNTYPE could be used to set the default DSNTYPE to EXTREQ for TYPE=RECEIVE transfers. However, this only works for TYPE=RECEIVE transfers and won't apply to TYPE=SEND transfers.
There is the ability to use LDSNTYPE to allow TYPE=SEND PDS transfers to be allocated as a LIBRARY when LDSNTYPE=LIBRARY is set at the partner.
Engineering are planning some changes in this area to help clarify how you can allocate extended format data sets for your transfers.
Additional Information
This article will be updated after the planned changes by Engineering are released in a PTF.
Related existing PTFs:
LU07501-"WRONG DSNTYPE IF USING A DEST/GROUP MEMBER WITH MODEL="
LU07599 - "ZOS<-ZOS RECEIVE TRANSFER DOES NOT USE DSNTYPE VALUE"
Feedback
