On 7 July 2017 at 09:30, John McKown <[email protected]> wrote:
> There are no control possible for this. The ISPF statistics are simply > data in the "user data area" portion of a member's directory entry. > https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.f54mc00/ispmc28.htm > > how a PDS directory entry is formatted: > https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.idad400/pdsd.htm > > Binyamin mentioned ACF2, but a regular program can use the STOW macro to > update a PDS directory entry. In fact, must be able to in order to add, > delete, or update (other than "in place") a member. I doubt, that even ACF2 > has any control to disallow updating the directory entry of a member in a > DSN to which the user has update authority. It will surprise me if IBM hasn't given some serious thought to this for PDSEs. A formally managed interface to PDSE member metadata, subject to RACF etc. controls, would be quite doable. Of course it would be tricky to make it compatible, but since you already can't do EXCP to a PDSE, it might not be so hard to capture STOW and subject it to security controls. Or provide a brand new member metadata API that is unrelated to the existing directory userdata. > Bottom line: ISPF statistics are NOT ANY GOOD for any kind of security or > auditing purposes. User can update them easily using 3.5 and you can't stop > them. You would need a product such as PDSMAN > https://docops.ca.com/ca-pdsman/7-7/en/administrating/what-is-pdsman How does PDSMAN or similar help with this? By avoiding ever having direct access to the PDS? Tony H. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
