I *believe* the ability to defeat SMF 42 applies only to PDS, not PDSE. I recall that when I pitched my former product -- which monitored SMF 42 with real-time alerting -- that that is what I told customers.
I know you can read a PDSE directory "magically" with BSAM. I believe that ability is read-only. I think an attempt to open DD MY.PDSE,DISP=OLD for output would fail. I don't think the PDSE API is exactly security-by-obscurity in this case. I would be willing to bet you that if you used the mystery API to change a PDSE directory -- either by purchasing the IBM documentation, or by hacking it out on your own -- that SMF 42 would report the change. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Monday, November 16, 2020 10:43 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Members Deleted was (Offsets SMF17) On Mon, 16 Nov 2020 10:23:57 -0800, Charles Mills wrote: >SMF Type 42 subtypes 20 and/or 21 will give you that information: 21 for >straight member delete, and 20 for PDSE directory re-initialize. I don't >think type 17 is relevant to this problem. > >Be aware that it is possible for a malicious programmer to defeat it: if a >program opens a PDS as a BSAM dataset and manipulates the directory directly >that will not be reflected in SMF Type 42, although SMF 15 would show that a >PDS was closed for xSAM output -- and there would be no corresponding SMF >Type 42. Although I suppose it might be possible to defeat that check also. > Is PDSE more robust? I believe one can open a PDSE as a BSAM data set and read but not write the directory directly (it fakes it?) And IBM provides some security-by-obscurity by concealing PDSE details (except for a high price). ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
