Provide support on DS8910F for DADSM UNMAP function in Copy Services relationships to allow use of Erase on Scratch on z/OS without unacceptable overhead

Our DASD environment is all-flash DS8910F, mirrored across a distance of approx 25km. In order to satisfy audit requirements, we recently enabled Erase On Scratch via RACF (SETROPS ERASE (ALL)). Unfortunately this created an unacceptable overhead in several critical batch jobs. This is because the Erase on Scratch function is synchronous and delays the running job while the erase function is being carried out. Two examples are: 

1) A CICS-based online banking system which uses IDCAMS DELETE processing to rename files on a daily basis updated in the overnight batch to become the next day's CICS Online files, where elapsed time increased from 10secs to 9mins and CPU time from 1sec to 10secs. This meant that the system was unavailable for 10 minutes instead of the 10 seconds that it previously took to rename the files. 

2) Db2 Online Reorgs, where internal deletion of temporary datasets caused unavailability on a daily basis of our mobile banking system for several minutes.

We opened a case with IBM (TS011478055) which suggested that the UNMAP feature is the IBM solution to erase residual data in an all-flash environment. However, UNMAP is currently NOT supported for datasets on volumes that are in Copy Services relationships, and so we cannot use this feature until this support is provided. We subsequently reverted the RACF SETROPTS command and service immediately returned to the previous performance level.

This idea is asking for the UNMAP feature to be supported for volumes in copy services relationships, so that we can comply with our Audit requirement to erase all scratched datasets including temporary datasets. We submit that many other customers will come under pressure to have this control in place in the near future due to the ever increasing focus on data security.