Re: Odd SMF 30 data within IEFACTRT (Part 2)

Thank you Jim, nice to know that THAT field is unimportant from now on. I did find this in one of the manuals (2.3 SMF) ... SMF30PSC 8 Binary Number of CPU page seconds for this address space, in page millisecond units. (A page millisecond unit equals 1.024 milliseconds.)

Re: Odd SMF 30 data within IEFACTRT (Part 2)

Discussion List <IBM-MAIN@LISTSERV.UA.EDU> wrote on 11/09/2017 12:48:05 PM: > From: "Daniel S. Dalby" <zos.j...@gmail.com> > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 11/09/2017 01:35 PM > Subject: Re: Odd SMF 30 data within IEFACTRT (Part 2) > Sent by: IB

Re: Odd SMF 30 data within IEFACTRT (Part 2)

stand it fully and all of its implications. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Daniel S. Dalby Sent: Thursday, November 9, 2017 9:48 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Odd SMF 30 data within IEFACTRT (Part 2)

Re: Odd SMF 30 data within IEFACTRT (Part 2)

You are correct Charles, some are fairly simple and I've got code to format milliseconds/microseconds. I just can't create these 4 fields on our systems and was wondering if anyone else has seen/formatted these fields. If not I'll just assume they are what the macro says and format them

Re: Odd SMF 30 data within IEFACTRT (Part 2)

then that is a pretty common sort of thing, no? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of DanD Sent: Thursday, November 9, 2017 8:32 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Odd SMF 30 data within IEFACTRT (Part 2

Odd SMF 30 data within IEFACTRT (Part 2)

Thanks to all who responded to my previous post. After 40 years in the business I learned something new...amazing ;-) Truth is, while processing the SMF30 this is the ONLY section (zEDC Usage Statistics Section) that I encountered which has an offset/length and a ZERO count. From this point

Re: AW: Odd SMF 30 data within IEFACTRT

Thank you peter. You are correct and this was entirely my mistake. I (incorrectly) assumed that if an offset and length existed for a SMF30 segment that there must be at least 1. WRONG, I need to check all three for non-zero values. With the SMF that I've processed so far over the last couple

Re: Odd SMF 30 data within IEFACTRT

-MAIN@LISTSERV.UA.EDU] On > Behalf Of DanD > Sent: Monday, November 6, 2017 2:33 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Odd SMF 30 data within IEFACTRT > > Thanks everyone. > > I WILL check all 3 fields for zeros in the future. > It's still odd that th

Re: Odd SMF 30 data within IEFACTRT

cussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of DanD Sent: Monday, November 6, 2017 5:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Odd SMF 30 data within IEFACTRT Thank you Berry, "As noted, the Length value of zero is now used to indicate that the actual length is in th

Re: Odd SMF 30 data within IEFACTRT

Thank you Berry, "As noted, the Length value of zero is now used to indicate that the actual length is in the first two bytes at the offset, if COUNT is non-zero." Do you know of a field where this is the case? I've never seen that. Thanks again, Dan

Re: Odd SMF 30 data within IEFACTRT

@LISTSERV.UA.EDU Subject: Re: Odd SMF 30 data within IEFACTRT Thanks everyone. I WILL check all 3 fields for zeros in the future. It's still odd that the 1st record has an offset and length but the count is zeros... "Here's the section your looking for ... it's this big ... and there are NONE&qu

Re: Odd SMF 30 data within IEFACTRT

it is. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of DanD Sent: Monday, November 6, 2017 12:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Odd SMF 30 data within IEFACTRT Thanks everyone. I WILL check all 3 fields for zeros

Re: Odd SMF 30 data within IEFACTRT

Thanks everyone. I WILL check all 3 fields for zeros in the future. It's still odd that the 1st record has an offset and length but the count is zeros... "Here's the section your looking for ... it's this big ... and there are NONE" what? ;-) Dan

Re: Odd SMF 30 data within IEFACTRT

I suspect you’re trying to process records with “only” EXCP sections - so probably not the first one cut by the address space in this interval. SMF 30 can cut multiple - if there are enough EXCP sections. Cheers, Martin Sent from my iPad > On 6 Nov 2017, at 16:24, DanD

Re: Odd SMF 30 data within IEFACTRT

rles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of DanD Sent: Monday, November 6, 2017 8:24 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Odd SMF 30 data within IEFACTRT I still find this a little odd but it's explainable. The OFFSET field

Re: Odd SMF 30 data within IEFACTRT

I still find this a little odd but it's explainable. The OFFSET field has a value but the COUNT field is zero. SMF30USO=04C8 SMF30USL=0040 SMF30USN= Why give an offset and length of a null segment. Weird, but I can code around it. Thanks for waking me up ;-) Dan

Re: Odd SMF 30 data within IEFACTRT

Thanks for having such great eyes. I thought they looked like TOD values. Not sure what the problem is... the base for the SMF record is in R5 and the offset to the field I'm interested in is in R1 ... ICM R15,15,SMF30USO Offset To Section BZGETSM800B. If No

Re: Odd SMF 30 data within IEFACTRT

2017 12:03 Subject: Re: Odd SMF 30 data within IEFACTRT Sent by:IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> I am sure that he is *not* mapping a zEDC section. It's plainly obvious, regardless of the embedded EBCDIC characters, that the data doesn't match. As a m

Re: Odd SMF 30 data within IEFACTRT

I am sure that he is *not* mapping a zEDC section. It's plainly obvious, regardless of the embedded EBCDIC characters, that the data doesn't match. As a matter of fact, I can tell that it's looking at a couple of EXCP sections. Not that it matters much; the program needs to be debugged. sas

Re: Odd SMF 30 data within IEFACTRT

Dan, starting in the middle of SMF30_US_ComprReq I see x'E2E3C5D7D3C9C2' which is 'STEPLIB', starting in SMF30_US_Def_UncomprIn I see x'E2E8E2D7D9C9D5E3', which is 'SYSPRINT'. Are you sure you are properly pointing to the zEDC section? On 11/04/2017 09:17 PM, DanD wrote: > I've been

AW: Odd SMF 30 data within IEFACTRT

s.j...@gmail.com> An: IBM-MAIN@LISTSERV.UA.EDU Betreff: Odd SMF 30 data within IEFACTRT Datum: 04.11.17, 19:18 I've been looking at various data available within the IEFACTRT exit's SMF 30 record. We're running zOS 2.2 and are quite current on maintenance. I must note that this is on

Re: Odd SMF 30 data within IEFACTRT

This is just a test IEFACTRT exit that I have to examine the various fields in the SMF30 record. In this case it simply goes to the zEDC Usage Statistics Section and formats the fields in that section in hex. Thanks, Dan --

Re: Odd SMF 30 data within IEFACTRT

. Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of DanD > Sent: Saturday, November 04, 2017 11:18 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Odd SMF 30 data within IEFACTRT > > I've been looking at vario

Odd SMF 30 data within IEFACTRT

I've been looking at various data available within the IEFACTRT exit's SMF 30 record. We're running zOS 2.2 and are quite current on maintenance. I must note that this is on a zPDT box which may or may not make a difference. The data that I find odd is in the "zEDC Usage Statistics Section".