Alas, [email protected] is my IBM address. I generally use my personal account for mailing lists and open source involvement as that transcends my employer. Sorry if that was confusing; I didn’t mean it to be.
Matt Hogstrom [email protected] “It may be cognitive, but, it ain’t intuitive." — Hogstrom > On Jan 13, 2020, at 12:40 PM, Paul Gilmartin > <[email protected]> wrote: > > On Sun, 12 Jan 2020 19:41:07 -0500, Matt Hogstrom wrote: > >> That was my thinking too Paul. We should be able to mask a lot of this in >> software and not have to do a lot of unnecessary “busy” work. >> >> Part of the challenge is to identify some behaviors that could be >> deprecated. We have a lot of baggage in the z/OS wagon. The defrag >> comment got me to thinking about possibilities that we at Ibm might start to >> consider >> > "we at Ibm"? But I see no IBM in your return address. But some prefer to > avoid such identification. > > --------------------------------------------- > On Mon, 13 Jan 2020 10:21:22 -0600, Tom Marchant wrote: >> >> ..., 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. >> ... >> 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. >> > Paging needs to be close to the hardware for performance. Spool > less so. Early OS just used Classic data sets for spool. There were > operational problems, addressed by HASP. IBM, characteristically, > did not make such enhancements generally available, but restricted > them to HASP/JES. > >> 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. >> > Tunnel vision. Indexing? > https://en.wikipedia.org/wiki/Btrfs > > As readers familiar with my biases, I'd urge that such enhancements > ignore older conventions and concentrate on PDSE and zFS which have > already overcome some of the older limitations. > > Does PDSE versioning exploit CoW? > > -- gil > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
