Performance impact of ACF2 Autoerase/Erase on Scratch
search cancel

Performance impact of ACF2 Autoerase/Erase on Scratch


Article ID: 139223


Updated On:


ACF2 ACF2 - DB2 Option ACF2 for zVM ACF2 - z/OS ACF2 - MISC


ACF2 STIG  ACF0270 performance and turning related to the ACF2 AUTOERAS GSO option.


Release : 16.0

Component : CA ACF2 for z/OS


There are two options for Auto erase(erase on scratch(EOS)), ACF2 erase-on-scratch and SAF(DFSMS) EOS.

When the ACF2 method is selected, CA ACF2 is responsible for erase-on-scratch support. CA ACF2 intercepts in erase processing gain control when a data set is deleted or released and interpret the NON-VSAM, VSAM, and VOLS AUTOERAS record settings to determine if the data set should be erased or not. You can only exclude by volume for non-vsam, there is no way to exclude some VSAM datasets.

When the SAF method is selected, CA ACF2 supports native DFSMS capabilities which can optionally erase a data set when deleted or released. It uses the ERASEALL, SECLEVEL, and SECLVL AUTOERAS records settings and optionally the PROFILE(ERASE) records to determine if the data set should be erased. You control the specific data sets that are to undergo erase-on-scratch processing with the SAF method

Auto erase(erase on scratch(EOS)) performance is based on the number, size and types of datasets or volumes selected for EOS. EOS performance overhead for auto erase would be incurred at delete by the job/task that is doing the delete because AUTOERAS elongates the SCRATCH process quite a bit. The other cause of possible degraded performance is that a RESERVE macro is issued by DADSM prior to calling us (IGGPRE00), and the reserve contention can be dramatic on work packs with heavy delete/define activity.