Receiving Top Secret Security Violation On Maskable Resource Even Though User Permitted

Products

• Top Secret

Issue/Introduction

A package failed and the programs in it had invalid binds. It was missed and when a plan was run, rather than getting a DB2 error, the problem manifested itself as an access violation to the tables being accessed. The ACID that got the violation was the PLAN OWNER.

Resolution

Check the DB2 facility to see if the NORES or RES facility control option is set. If NORES is set, this needs to be changed to RES so rules for prefixed resources get loaded into the security record for the user.

NORES on a FACILITY means permits for maskable resources will not be loaded into the user's security record when the user signs on. This would mean that the user is not authorized even though the user has a PERMIT for the maskable resource because the permission was never loaded in storage.

NORES was used to conserve storage in the olden days. RES means that all permissions are loaded into storage. Since the user record is now loaded in 31 bit hight private, there are no longer storage concerns when specifying RES on a facility.

When changing from NORES to RES on a FACILITY, a recycle of the region is required to pick up the change.