This is the public portal for all IBM Z Hardware and Operating System related offerings. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).
We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:
Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,
Post an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.
IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.
ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.
The data class documentation in DFSMSdfp Storage Administration says "If you alter a data class definition, SMS applies the changes to any new data sets that use the data class after you activate the changed configuration. However, SMS does not retroactively apply your changes to previously allocated data sets. To apply your changes to existing data sets, you need to delete and redefine the data sets."
According to the previous comment, that is not true for the three extent-constraint removal options and the book should be corrected to cite this exception.
I don't know that everyone would agree that the default should be YES, since then you would have the opposite problem of non-critical applications potentially being able to extend to the point of impacting critical work loads. I've been watching the votes and so far no others have voted for this. So at this point I will decline this, but if you want to try for more votes you can submit to the ISMF group since VSAM does not control or store this value.
I would expect this change to the DATACLAS definition itself should take effect without the need for a reorg of the dataset because it is not changing any formatting or compression attributes. The dataset may possibly need to closed and reopened to refresh the in-storage control blocks to reflect the change. You certainly have to redefine to pick up a new DATACLAS as the existing one assigned cannot be changed, but this is not changing the assigned DATACLAS. I am sure we have changed the DYNVOL values in DATACLASes before without any issues but I can't recall if it affected DB2 datasets.
The system applies most options in data class only when a data set is created. Subsequent changes to the data class definition have no effect on existing data sets. This proposed option would be an exception.
Also keep in mind that each volume can hold no more than 123 extents. In order to have 7257 extents, the data set must reside on 59 volumes and every volume was able to get 123 extents.