Re: Members Deleted was (Offsets SMF17)

2020-11-16 Thread Charles Mills
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


Re: Members Deleted was (Offsets SMF17)

2020-11-16 Thread Paul Gilmartin
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).

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: Members Deleted was (Offsets SMF17)

2020-11-16 Thread Charles Mills
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.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Steely.Mark
Sent: Monday, November 16, 2020 10:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Members Deleted was (Offsets SMF17)

At one time did IBM says that SMF reporting would also be done at the member
level. I need to find the date, time & ID  a member was deleted. 

If this is the case does anyone have a process to do this. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: Members Deleted was (Offsets SMF17)

2020-11-16 Thread Sri h Kolusu
> At one time did IBM says that SMF reporting would also be done at
> the member level. I need to find the date, time & ID  a member was
deleted.
>

Mark,

For member deletions you need to extract TYPE 42 and sub-type 21

Subtype 21 is written when a member is deleted from a PDS or a PDSE to
indicate who or what (job, started task, or TSO user) deleted the member.
It contains the name of the data set and the volume serial of the volume on
which it resided, including all the aliases of the member that fits in the
SMF record.

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.ieag200/rec42.htm

So use the following JCL

//STEP0100 EXEC PGM=SORT
//SYSOUT   DD SYSOUT=*
//SORTIN   DD DISP=SHR,DSN=Your SMF dataset
//SORTOUT  DD SYSOUT=*
//SYSINDD *
  OPTION COPY,VLSCMP
  INCLUDE COND=(06,01,BI,EQ,42,AND,  $ TYPE 42
23,02,BI,EQ,21)  $ SUBTYPE 21
/*


Further if you have any questions please let me know

Thanks,
Kolusu
DFSORT Development
IBM Corporation



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Members Deleted was (Offsets SMF17)

2020-11-16 Thread Steely.Mark
At one time did IBM says that SMF reporting would also be done at the member 
level. I need to find the date, time & ID  a member was deleted.

If this is the case does anyone have a process to do this.

Thank You

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Sri 
h Kolusu
Sent: Friday, November 06, 2020 10:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Offsets SMF17

ATTENTION: This e-mail came from an external source. Do not open attachments or 
click on links from unknown or unexpected emails.


> I want to make a list of the files that have been deleted, from SMF
> record 17, and it must be offsets but nothing comes out.
> can you help me?


Jordi,

As others mentioned, your offsets are off.  SMF17 layout is pretty straight 
forward. So you can code DFSORT symbols and use them instead of hard coding the 
offsets. So use the following job

//STEP1EXEC PGM=ICETOOL
//TOOLMSG  DD SYSOUT=*
//DFSMSG   DD SYSOUT=*
//SYMNOUT  DD SYSOUT=*
//SYMNAMES DD *
SMF17RDW,1,04,BI
  SMF17LEN,=,02,BI
  SMF17SEG,*,02,BI
SMF17FLG,*,01,BI
SMF17RTY,*,01,BI
SMF17TME,*,04,BI
SMF17DTE,*,04,PD
SMF17SID,*,04,CH
SMF17JBN,*,08,CH
SMF17RST,*,04,BI
SMF17RSD,*,04,PD
SMF17UID,*,08,CH
SMF17RIN,*,02,BI
SMF17DSN,*,44,CH
 SMF17DSNF,=,04,CH
 SMF17DSNR,*,40,CH
SMF17RV1,*,03,BI
SMF17NVL,*,01,BI
SMF17RV2,*,02,BI
SMF17FVL,*,06,CH
/*
//RAWSMF   DD DISP=SHR,DSN=SA$SF.ALL.M.GEN1.YEAR2011.DATA.G0001V00
// DD DISP=SHR,DSN=SA$SF.ALL.M.GEN1.YEAR2011.DATA.G0002V00
// DD DISP=SHR,DSN=SA$SF.ALL.M.GEN1.YEAR2011.DATA.G0003V00
// DD DISP=SHR,DSN=SA$SF.ALL.M.GEN1.YEAR2011.DATA.G0004V00
//SMF  DD DSN=&,SPACE=(CYL,(15,15)),UNIT=SYSDA
//SMFREP   DD DSN=SA80855.GENX.SMF17.TXT,
//UNIT=3390,DISP=(,CATLG),
//SPACE=(CYL,(2,2),RLSE)
//TOOLIN   DD *
  COPY FROM(RAWSMF) TO(SMF) USING(SMFI)
  DISPLAY FROM(SMF) LIST(SMFREP) -
  BETWEEN(2) -
  LINES(999) -
  BLANK  -
  TITLE('SMF-17 : WHO DELETED DATASETS') DATE TIME PAGE  -
  HEADER('SMF')   ON(SMF17RTY)   -
  HEADER('SYS')   ON(SMF17SID)   -
  HEADER('DATE')  ON(SMF17DTE,DT1,E'/99/99') -
  HEADER('TIME')  ON(SMF17TME,TM1,E'99:99:99')   -
  HEADER('JOB')   ON(SMF17JBN)   -
  HEADER('USER')  ON(SMF17UID)   -
  HEADER('DATASET DELETED') ON(SMF17DSN) -
  HEADER('-VOLS') ON(SMF17NVL)   -
  HEADER('VOLSER') ON(SMF17FVL)
/*
//SMFICNTL DD *
  OPTION VLSCMP,SPANINC=RC0
  INCLUDE COND=(SMF17RTY,EQ,17,AND,  $ TYPE 17
SMF17DSN,EQ,C'UCAT')  $ SMF17DSN = UCAT

  SORT FIELDS=(SMF17DTE,A,   $ SMF17DTE
   SMF17TME,A)   $ SMF17TME
/*


Just in case the format is messed up here, I am going to send the solution as a 
text mail offline.

Thanks,
Kolusu
DFSORT Development
IBM Corporation



--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
*** Disclaimer ***
This communication (including all attachments) is solely for the use of the 
person to whom it is addressed and is a confidential AAA communication. If you 
are not the intended recipient, any use, distribution, printing, or copying is 
prohibited. If you received this email in error, please immediately delete it 
and notify the sender.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN