On Sun, 12 Jan 2020 13:59:21 -0500, Matt Hogstrom wrote: >it occurred to me that for the most part a lot of the work in defragging, >worrying about disk geometry and other issues are really not / less of >an issue with cache and SSD technologies.
No, as long as z/OS still allocates data set space in a small number of extents when the data set is defined, these are still issues. I suppose that z/OS could be modified so that all data sets have an arbitrary, very large number of tracks (or other allocation units if FBA is supported). In that case, is the information about where the next track is kept in the VTOC, potentially requiring a much larger VTOC, or does each track contain some kind of link to the next track? The latter would seem to change the amount of available space on each track Can the pointer to the next track be on a different volume? One might argue that the notion of volumes is no longer as useful as it was with emulated volumes. That might be a valid argument, though eliminating the notion has consequences for things like spool volumes, page volumes. What happens when additional drives are added to a DASD subsystem? Can a data set be spread across multiple DASD subsystems? It is not clear to me that this kind of architectural change would be an improvement, especially for data sets that can be accessed randomly. -- Tom Marchant ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
