When I was a SE at EMC, I occasionally fielded questions from customers who had converted to VP.  They were wondering if they should discontinue their long-established weekly or monthly DF/DSS defrag jobs, since such activity seemed pointless in an environment where the z/OS host doesn't manage the physical data and everything is striped across the entire backend.

Recently I encountered a situation on our virtually-provisioned 20K. A large DB2 catalog could not be relocated to a new SMS SG. It received IDCAMS RC=0028 errors indicating a secondary extent could not be allocated. There was plenty of free space across the SG, but ISMF panels indicated the fragmentation index on all the volumes was very high-- above 500.  I ran a DF/DSS defrag job against the SG and the fragmentation indices dropped below 50 on the volumes. I then resubmitted the catalog move job, and it was successful; the catalog was reduced from 201 extents to 55 after the move.

It seems to me that fragmentation, of a sort,  still occurs. I wonder if the metadata constructs in cache that represent tracks on the virtual "3390" devices the host sees have a way of getting "fragmented" or out of continuity. I remember when we were showing customers the virtual devices with TF SNAP, we would remind them that the longer a SNAP volume stayed in use, more and more track pointers would be needed to access the changed tracks as updates were made.  I'm wondering if a similar situation occurs with virtually provisioned 3390 devices, and whether a defrag job relocates the track pointers more efficiently.