On Sun, 12 Jan 2020 13:59:21 -0500, Matt Hogstrom wrote: >Out of curiosity, its been a while since I did storage admin but 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. So, perhaps naive on my part, but it would seem to me >the work to “defrag” is really more to keep up the legacy z/OS concepts like # >of extents, CKD processing for PDS’, etc. Are there benefits to defragging >these days apart from the consequences of the limitations from older >architectures and paradigms like directory blocks and member placement? > Alas, while the new technologies bypass the performance impact of fragmentation, insofar as they faithfully emulate older hardware it's still possible to have virtual space exhaustion. Aren't PDSes still limited to 65,535 virtual tracks? PDSEs are better at reclaiming space.
I could imagine a Super-IEBCOPY's updating directory blocks and DS1LSTAR and reclaiming space so virtually freed. Only imagine. Even as SSD firmware moves and remaps physical blocks to counteract fatigue. >-----Original Message----- On Sun, 12 Jan 2020 09:32:01 -0800, Charles Mills wrote: >When you compress a PDS aren't you essentially de-fragging it? No, not the >way the word is used on PC disks, but you are essentially consolidating >fragments of free space into one big chunk of free space. > >-----Original Message----- >From: Jeremy Nicoll >Sent: Sunday, January 12, 2020 1:28 AM > >I dunno about the first bit, but "routine mainframe defrag" is fine. >DFDSS has a DEFRAG verb. > I used to believe that DB2 might require a REPRO to reclaim orphaned CA/CIs. Is that still the case? -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
