Re: Help identifying source of SMF 80 record

[Charles Mills]

Rub it in!

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of David Crayford
Sent: Wednesday, July 06, 2016 6:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Help identifying source of SMF 80 record

Should be the first port of call! Cheryl is the doyen of SMF knowledge,
along with Dr Merrill :)

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

Re: Help identifying source of SMF 80 record

[David Crayford]

Should be the first port of call! Cheryl is the doyen of SMF knowledge, 
along with Dr Merrill :)



On 6/07/2016 8:58 PM, Charles Mills wrote:

Well how dumb can I get. I never thought to look at your list, @Cheryl.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Cheryl Watson
Sent: Tuesday, July 05, 2016 11:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Help identifying source of SMF 80 record

Hi Charles,

I've got an EKC product called "Firecall" listed in my SMF Reference Summary
at www.watsonwalker.com/references.html.

--
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

Re: Help identifying source of SMF 80 record

[Charles Mills]

Well how dumb can I get. I never thought to look at your list, @Cheryl.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Cheryl Watson
Sent: Tuesday, July 05, 2016 11:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Help identifying source of SMF 80 record

Hi Charles,

I've got an EKC product called "Firecall" listed in my SMF Reference Summary
at www.watsonwalker.com/references.html.

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

Re: Help identifying source of SMF 80 record

[Cheryl Watson]

Hi Charles,

I've got an EKC product called "Firecall" listed in my SMF Reference Summary
at www.watsonwalker.com/references.html.

Best regards,
Cheryl

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Tuesday, July 5, 2016 11:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Help identifying source of SMF 80 record

X-posted IBM-MAIN and RACF-L.

I am looking at an SMF 80 record from a customer that I am having trouble
making sense of. The customer is definitely a RACF user, not a TSS user. The
customer I believe is on z/OS V2R1.

It is a valid SMF 80 record. The event.qualifier is 2.0. There are three
relocatable sections: a 49 (User Name) that says "Detection Status", a 17
(Class name) that says "EK$CLASS" and a 1 (Resource Name) that says
"EKCA.SECURITY.DETECTION". The record is 2959 bytes long, long for a RACF
SMF record.

So what's odd about it?

1. It is missing the RACF version SMF80VRM at offset 80 that was added to
RACF around OS/390 V1R2. That leads me to believe the record was not
produced by RACF.

2. Between roughly offset x'44' and offset x'B52' (the first relocatable
section) there is binary data that looks like perhaps a series of binary
counters that I am not familiar with. No recognizable EBCIDC data providing
a clue.

Does anyone have an idea what might be producing this record and where its
format might be documented?

It's at a customer so I don't have a thorough knowledge of what third-party
products might be running, etc., etc.

Thanks,

Charles 

--
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

Re: Help identifying source of SMF 80 record

[Vernooij, CP (ITOPT1) - KLM]

You could set up an SMF exit to check for the suspicious record and check who 
is writing it.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: 05 July, 2016 17:43
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Help identifying source of SMF 80 record

X-posted IBM-MAIN and RACF-L.

I am looking at an SMF 80 record from a customer that I am having trouble
making sense of. The customer is definitely a RACF user, not a TSS user. The
customer I believe is on z/OS V2R1.

It is a valid SMF 80 record. The event.qualifier is 2.0. There are three
relocatable sections: a 49 (User Name) that says "Detection Status", a 17
(Class name) that says "EK$CLASS" and a 1 (Resource Name) that says
"EKCA.SECURITY.DETECTION". The record is 2959 bytes long, long for a RACF
SMF record.

So what's odd about it?

1. It is missing the RACF version SMF80VRM at offset 80 that was added to
RACF around OS/390 V1R2. That leads me to believe the record was not
produced by RACF.

2. Between roughly offset x'44' and offset x'B52' (the first relocatable
section) there is binary data that looks like perhaps a series of binary
counters that I am not familiar with. No recognizable EBCIDC data providing
a clue.

Does anyone have an idea what might be producing this record and where its
format might be documented?

It's at a customer so I don't have a thorough knowledge of what third-party
products might be running, etc., etc.

Thanks,

Charles 

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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

Re: Help identifying source of SMF 80 record

[Charles Mills]

Well, I did say they were RACF users.

ACF2 does not generally cut Type 80 records, although its default Type 230
record could be overridden to 80 if the customer desired. (TSS by default
does cut Type 80 records.) This does not look like an ACF2 record; I would
recognize that. The record is very much "RACF-like." It is in fact a valid
"RACF" Type 80 record, although there is a lot of unaccounted for data in
the middle. Because of the pointer architecture of the RACF record layout,
extra data in the middle does not affect the validity of the  layout of the
"RACF-like" portions.

> I don't think there's anything stopping ANY software from confecting SMF
80 records.

Well, there's "anything" if you count APF. But your point is well taken --
it could be almost any program or product cutting an SMF 80 record. It would
not have to be a security product or a "RACF add-on."

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Martin Packer
Sent: Tuesday, July 05, 2016 11:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Help identifying source of SMF 80 record

Nobody has mentioned ACF2 yet. Is that a possibility?

In principle I don't think there's anything stopping ANY software from
confecting SMF 80 records.

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

Re: Help identifying source of SMF 80 record

[Martin Packer]

Nobody has mentioned ACF2 yet. Is that a possibility?

In principle I don't think there's anything stopping ANY software from 
confecting SMF 80 records.

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Cloud & Systems Performance, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker

Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker

Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or 
  
https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2



From:   Charles Mills <charl...@mcn.org>
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   05/07/2016 18:10
Subject:    Re: Help identifying source of SMF 80 record
Sent by:IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>



Thanks, @Tony and @Hayim. Sounds like you might well have it. We will look 
into it.

> We've encountered a handful of ISV products over the years that write 
"RACF" SMF records

Yeah, I have encountered at least one other, actually a homegrown product 
that writes Type 80 records.

Even TSS kind of fits this description. The primary TSS SMF record is Type 
80 and is "almost" like what RACF writes -- or rather, like what RACF 
wrote about twenty or thirty years ago.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
Behalf Of Tony Harminc
Sent: Tuesday, July 05, 2016 9:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Help identifying source of SMF 80 record

On 5 July 2016 at 11:43, Charles Mills <charl...@mcn.org> wrote:
> I am looking at an SMF 80 record from a customer that I am having 
> trouble making sense of. The customer is definitely a RACF user, not a 
> TSS user. The customer I believe is on z/OS V2R1.
>
> It is a valid SMF 80 record. The event.qualifier is 2.0. There are 
> three relocatable sections: a 49 (User Name) that says "Detection 
> Status", a 17 (Class name) that says "EK$CLASS" and a 1 (Resource 
> Name) that says "EKCA.SECURITY.DETECTION". The record is 2959 bytes 
> long, long for a RACF SMF record.
>
> So what's odd about it?
>
> 1. It is missing the RACF version SMF80VRM at offset 80 that was added 
> to RACF around OS/390 V1R2. That leads me to believe the record was 
> not produced by RACF.

Yup. We've encountered a handful of ISV products over the years that write 
"RACF" SMF records on their own initiative. None of them is fully 
"correct", either in that the record itself would never be written by 
RACF, or that it wouldn't be written in the context it is.

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



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

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

Re: Help identifying source of SMF 80 record

[Charles Mills]

Thanks, @Tony and @Hayim. Sounds like you might well have it. We will look into 
it.

> We've encountered a handful of ISV products over the years that write "RACF" 
> SMF records

Yeah, I have encountered at least one other, actually a homegrown product that 
writes Type 80 records.

Even TSS kind of fits this description. The primary TSS SMF record is Type 80 
and is "almost" like what RACF writes -- or rather, like what RACF wrote about 
twenty or thirty years ago.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Harminc
Sent: Tuesday, July 05, 2016 9:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Help identifying source of SMF 80 record

On 5 July 2016 at 11:43, Charles Mills <charl...@mcn.org> wrote:
> I am looking at an SMF 80 record from a customer that I am having 
> trouble making sense of. The customer is definitely a RACF user, not a 
> TSS user. The customer I believe is on z/OS V2R1.
>
> It is a valid SMF 80 record. The event.qualifier is 2.0. There are 
> three relocatable sections: a 49 (User Name) that says "Detection 
> Status", a 17 (Class name) that says "EK$CLASS" and a 1 (Resource 
> Name) that says "EKCA.SECURITY.DETECTION". The record is 2959 bytes 
> long, long for a RACF SMF record.
>
> So what's odd about it?
>
> 1. It is missing the RACF version SMF80VRM at offset 80 that was added 
> to RACF around OS/390 V1R2. That leads me to believe the record was 
> not produced by RACF.

Yup. We've encountered a handful of ISV products over the years that write 
"RACF" SMF records on their own initiative. None of them is fully "correct", 
either in that the record itself would never be written by RACF, or that it 
wouldn't be written in the context it is.

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

Re: Help identifying source of SMF 80 record

[Tony Harminc]

On 5 July 2016 at 11:43, Charles Mills  wrote:
> I am looking at an SMF 80 record from a customer that I am having trouble
> making sense of. The customer is definitely a RACF user, not a TSS user. The
> customer I believe is on z/OS V2R1.
>
> It is a valid SMF 80 record. The event.qualifier is 2.0. There are three
> relocatable sections: a 49 (User Name) that says "Detection Status", a 17
> (Class name) that says "EK$CLASS" and a 1 (Resource Name) that says
> "EKCA.SECURITY.DETECTION". The record is 2959 bytes long, long for a RACF
> SMF record.
>
> So what's odd about it?
>
> 1. It is missing the RACF version SMF80VRM at offset 80 that was added to
> RACF around OS/390 V1R2. That leads me to believe the record was not
> produced by RACF.

Yup. We've encountered a handful of ISV products over the years that
write "RACF" SMF records on their own initiative. None of them is
fully "correct", either in that the record itself would never be
written by RACF, or that it wouldn't be written in the context it is.

> Does anyone have an idea what might be producing this record and where its
> format might be documented?

>From the names I'd guess it to be an EKC product. I'm not aware if
they have product(s) that work with RACF rather than ACF2 (I
understand the company was founded by one of the ACF2 initial
developers), but it seems likely.

http://www.ekcinc.com

Tony H.

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