ALERT: Some images may not load properly within the Knowledge Base Article. If you see a broken image, please right-click and select 'Open image in a new tab'. We apologize for this inconvenience.

How Does exactly work PDS Member Protection?

book

Article ID: 50010

calendar_today

Updated On:

Products

Cleanup Datacom DATACOM - AD CIS COMMON SERVICES FOR Z/OS 90S SERVICES DATABASE MANAGEMENT SOLUTIONS FOR DB2 FOR Z/OS COMMON PRODUCT SERVICES COMPONENT Common Services Datacom/AD CA ecoMeter Server Component FOC EASYTRIEVE REPORT GENERATOR FOR COMMON SERVICES INFOCAI MAINTENANCE IPC UNICENTER JCLCHECK COMMON COMPONENT Mainframe VM Product Manager CHORUS SOFTWARE MANAGER CA On Demand Portal CA Service Desk Manager - Unified Self Service PAM CLIENT FOR LINUX ON MAINFRAME MAINFRAME CONNECTOR FOR LINUX ON MAINFRAME GRAPHICAL MANAGEMENT INTERFACE WEB ADMINISTRATOR FOR TOP SECRET Xpertware Top Secret Top Secret - LDAP Top Secret - VSE

Issue/Introduction

Description:

Here is an example:

One PROCLIB is protected and allowed for READ access for all users. However, this PROCLIB contains members that need to be updated by some users.

To enable PDS Level Member Protection set PDSPROT CA Top Secret control options to ON. Example:

PDSPROT(ON)
PDSPROT(ADD,DSN(SYS1.SYSZ.PROCLIB),CLASS(PDSMEM1))

The following permission was given to a PROFILE:

TSS ADD(DeptOwner) PDSMEM1(ABC,D)
TSS PER(ProfileName) PDSMEM1(ABC,D) ACCESS(UPDATE)

which means all members starting with either ABC or D are protected PDS members.

When trying to testing the implementation:

An acid belonging to that PROFILE (ProfileName) tries to update member DEFGHI (Staring with letter " D") will fail with a S913 abend.

TSSUTIL report claims DRC66, which means access not granted to dataset. This is correct, because the profile only has READ access to that PROCLIB, SYS1.SYSZ.PROCLIB.

If UPDATE access is allowed for these acids, they will be able to update any member in the PROCLIB and not necessarily the ones allowed.

This behavior may confuse administrators wondering why any member can be updated.

Solution:

The behavior reported here is correct. It is due to the PDSMEMx resource classesNOT being protected by default. In other words the DEFPROT attribute is NOT set on the resource class.

If an acid has UPDATE access to a PROCLIB, it will be able to updateany member, belonging to that PROCLIB, which has not been defined to TSS (Not owned).

All defined member will be protected accordingly.

To avoid such behavior, you have to add the DEFPROT attribute to the PDSMEM1 class:

TSS REP(RDT) RESCLASS(PDSMEM1) ATTR(DEFPROT)

The class will be displayed as follows:

ACCESSORID = *RDT* NAME = RESOURCE DEFINITIONS
RESOURCE CLASS = PDSMEM1
RESOURCE CODE = X'043'
ATTRIBUTE = NOMASK,MAXOWN(08),MAXPERMIT(008),ACCESS,PRIVPGM,DEFPROT
ACCESS = NONE(0000),UPDATE(6000),READ(4000),ALL(FFFF)
DEFACC = READ
TSS0300I LIST FUNCTION SUCCESSFUL

All members will be protected as soon as a PROCLIB is added to the PDSMEMx resource class. You will have to authorize the member at the required access level.

Adding the DEFPROT ATTRIBUTE is NOT a requirement. Please refer to your site security standards to determine how you want to implement PDS Member Level Protection.

Environment

Release:
Component: AWAGNT