ACF2 VOLUME loggings occurring for volumes not in GSO SECVOLS

Products

• ACF2
• ACF2 - MISC
• ACF2 - z/OS

Issue/Introduction

During a record and rule cleanup, a volume was removed from the GSO SECVOLS record and added to the GSO RESVOLS record to allow access checks to occur at the dataset level instead of at the volume level. Rules in the $KEY(VOLUME) were also removed due to volume checks should no longer occur.

However, there are now thousands of VOLUME loggings from NON-CNCL batch users on various VOLUME.@volume resources.

It's not consistent, and seems to go on and off.

Why are these loggings happening at the volume level? Shouldn't the access checks be occurring at the dataset level since the volume is no longer in the GSO SECVOLS record?

Environment

Release : 16.0

Resolution

The batch jobs are performing operations in the DASDVOL class.

DASDVOL is a class that allows maintenance operations to occur at the volume level. It will always cause a volume access check to occur even if the volume in question is not in the GSO SECVOLS record.

There are a few options to make the loggings stop for NON-CNCL users:

1. Put the volume rules back for the batch logonids that these DASDVOL checks are occurring for. Dataset and volume access checks in ACF2 always go through rule validation before checking for NON-CNCL access.
   
   
2. Create a GSO MAINT record for the batch logonids performing maintenance operations. (This is the recommended method as these users are performing maintenance operations.)
   
   
3. Create a GSO SAFDEF record for the batch logonids that tell ACF2 to ignore the call but send a return code to the caller that access was allowed.