The 3.5 option has been able to manipulate member stats since I first saw "SPF" somewhere around 1980. The most useful function I have found is being able to delete member statistics. This is one way you can save a new member when the directory is out of space. It is usually my second choice after trying "STATS OFF" on the new member I am editing.
-----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Friday, July 07, 2017 8:31 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Friday question: ISPF Statistics Manipulation CAUTION: This email originated from outside of CA. Do not click links or open attachments unless you recognize the sender and know the content is safe. On Fri, Jul 7, 2017 at 8:05 AM, Barbara Nitz <nitz-...@gmx.net> wrote: > A colleague of mine just asked me if ISPF statistics in a data set, > especially the USERID field, can be manipulated. We used ISPF 3.5 and > we were both astonished that I was easily able to fake a userid as the > one who last changed a member (testing in my own dataset, of course). > > This immediately raised the question for me if there is any RACF > control that would prevent this type of manipulation, especially since > the userids in those statistics are widely used as evidence. Does > anyone know if there are such RACF controls? A quick search in the > ISPF books didn't turn up any hint. > 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ibm.com_support_knowledgecenter_en_SSLTBW-5F2.1.0_com.ibm.zos.v2r1.f54mc00_ispmc28.htm&d=DwIFaQ&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=_pjUpH7SxKBkB6gBZH_r7a7W1q59Nzy5lPxFUOMH-UM&m=4Nkmg4zgV8bvaZuf3pzQfmzQUNagnQX66musH9Nq2lY&s=gmQ7AOx3yGz72ixAbnTxOfFf3gqZ-Z7ugt_coMfx1DM&e= how a PDS directory entry is formatted: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ibm.com_support_knowledgecenter_en_SSLTBW-5F2.1.0_com.ibm.zos.v2r1.idad400_pdsd.htm&d=DwIFaQ&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=_pjUpH7SxKBkB6gBZH_r7a7W1q59Nzy5lPxFUOMH-UM&m=4Nkmg4zgV8bvaZuf3pzQfmzQUNagnQX66musH9Nq2lY&s=f80EEL_LypcCjkKc6P-Yiaqk55B20TIKjP7-qQsnRyo&e= 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. 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 > > Barbara > > -- Veni, Vidi, VISA: I came, I saw, I did a little shopping. Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
