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

[DanD]

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

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

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

[Jim Mulder]

Page-milliseconds is number of pages multiplied by number 
of milliseconds.  SMF30ERS will always contain zeros on 
zOS 1.6 or higher, since z/OS does not use expanded storage
in zArchitecture mode. 

Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY

IBM Mainframe 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: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>
> 
> 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 accordingly.
> I've never seen/heard of "page-milliseconds" before and was 
> wondering what format that was (divide by 4096 first?).  Again it's 
> zeros on our system.
> 
> Thanks.
> 
> --
> 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: Odd SMF 30 data within IEFACTRT (Part 2)

[Charles Mills]

I saw that "page-milliseconds." Hmm.

If all you are doing is reporting, then I guess just report it: 23.8 
page-milliseconds. I don't read "page" as "divide by 4K" but I suppose that is 
possible.

If you are analyzing, then of course you will need to understand 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)

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 accordingly.
I've never seen/heard of "page-milliseconds" before and was wondering what 
format that was (divide by 4096 first?).  Again it's zeros on our system.

Thanks.

--
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: Odd SMF 30 data within IEFACTRT (Part 2)

[Daniel S. Dalby]

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 accordingly.
I've never seen/heard of "page-milliseconds" before and was wondering what 
format that was (divide by 4096 first?).  Again it's zeros on our system.

Thanks.

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

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

[Charles Mills]

What sort of help are you looking for? Comments on the fields seem 
straightforward. If you want times in seconds.decimals (which I would think 
would be adequate, at least as a first cut) then the logic should be pretty 
obvious -- or am I missing something? If you want times hh:mm:ss.decimals 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)

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 on, I will ALWAYS check for all three before assuming 
that there is data at that offset.

I still have 4 fields in the SMF30 that I'm not sure how to format them.  Can 
anyone give a quick explanation of how these fields are formatted and if there 
are other fields in the SMF30 that are a similar format?
Is there any CBT code as an example for formatting the SMF30?   Can you point 
me to an IBM manual that explains this?

SMF30CRP DC   F'0' RqsvCPUtimeConsumedWhileCRMpromoted  
*  CPU time consumed for an address 
*  space or job while promoted due  
*  to chronic resource contention   
*  (in 1024 millisecond units). For 
*  interval records, this field 
*  contains only the time consumed  
*  during the interval itself. @LJA
…
SMF30ERS DSCL8' 'Expanded storage page residency
*time in page-milliseconds @DWA 
*   
…
SMF30_US_QueueTime DC DL8'0' Total queue time. The amount of time   
*in microseconds from when the request was  
*submitted until the adapter started
*executing the request.@0JA 
SMF30_US_ExecTime  DC DL8'0' Total execution time (in microseconds) 
*  @0JA

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

Re: Odd SMF 30 data within IEFACTRT

[Martin Packer]

Knowing the length of a section MIGHT be interesting, even if there are none of 
them. As it might indicate maintenance level (occasionally).

To be fair, I’d put it in the category of “interesting” but not necessarily 
“useful”. :-)

Cheers, Martin 

Sent from my iPad

> On 6 Nov 2017, at 22:43, Barry Merrill <ba...@mxg.com> wrote:
> 
> It is documented for many newer SMF records that the COUNT field is the
> sole indicator that there are in fact these segments in this record.
> The OFFSET seems always to be busy, and the value of the location of
> the next triplet, even when this is the last triplet.
> 
> As noted, the Length value of zero is now used to indicate that the
> actual length is in the first two bytes at the offsed, if COUNT is
> non-zero.
> 
> Barry
> 
> 
> Merrilly yours,
> 
> Herbert W. Barry Merrill, PhD
> President-Programmer
> Merrill Consultants
> MXG Software
> 10717 Cromwell Drive  technical questions: supp...@mxg.com
> Dallas, TX 75229
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.mxg.com=DwIFaQ=jf_iaSHvJObTbx-siA1ZOg=BsPGKdq7-Vl8MW2-WOWZjlZ0NwmcFSpQCLphNznBSDQ=iZuqNF3254ztNCrcdxK6gfQ5Iptbpeu3E3usulPRmChPA=Zf3L5YjVZ8H5zutL_KUf33-JuZKXrcPS6pFOYJSo5DI=
> admin questions: ad...@mxg.com
> tel: 214 351 1966
> fax: 214 350 3694
> 
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-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 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
> 
> --
> 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
> 
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: Odd SMF 30 data within IEFACTRT

[Barry Merrill]

All or almost all DB2 data can contain length=0 as documented 
in DB2 Maclib SDSNMACS members, for one example below.

Barry


./   ADD   NAME=DSNDQWA0,SSI=24351827
*   %DCL DSNDQWA0_LIST CHAR EXTERNAL;   0001
*   %IF DSNDQWA0_LIST ^= '' %THEN/* DSNDQWA0_LIST IS SET TO  */ 0002
* %GOTO QWA0_LIST_ON;/*YES FOR THE LISTING   */ 0003
*   @LIST PUSH; 0004
*   @LIST OFF;  0005
*   %QWA0_LIST_ON:; 0006
*   0007
*   %GOTO PLSPART_DSNDQWA0; 0008
*/*/0009
*/* MACRO-NAME = DSNDQWA0 */0010
*/* DESCRIPTIVE-NAME = DB2 SELF DEFINING SECTION MAPPING MACRO*/0011
*/* FOR ACCOUNTING IFCID=0003 */0012
*/*Licensed Materials - Property of IBM   */0013
*/*5615-DB2   */0014
*/*(C) COPYRIGHT 1982, 2013 IBM Corp.  All Rights Reserved.   */0015
*/*   */0016
*/*STATUS = Version 11*/0017
*/* FUNCTION = MAPPING MACRO FOR DB2 ACCOUNTING SELF DEFINING */0018
*/*SECTION FOR IFCID=0003 */0019
lines deleted
*/*/0055
0057
*/**IMPORTANT PARSING INFORMATION*IMPORTANT PARSING INFORMATION 0058
* * 0059
* The length field for any (offset,length,number of data sections)* 0060
* triplet can legally be zero with a non-zero offset.  This indicates * 0061
* this section is a varying length repeating group. A varying * 0062
* length repeating group is a series of related data blocks with  * 0063
* differing lengths. This is typically, if not always, the result of  * 0064
* varying length long name fields in the data block.  * 0065
* * 0066
* In order to parse a varying length repeating group, the following   * 0067
* steps should be taken:  * 0068
* 1. Follow the offset pointer to find the first member of the group. * 0069
* 2. Each member will be mapped as follows:   * 0070
*<2 byte member length>  * 0071
* * 0072
*The length of the first member will be in the 2 bytes pointed* 0073
*to by the offset pointer.  It is important to note that the  * 0074
*data section for the first member will start 2 bytes past the* 0075
*offset pointer.  * 0076
* 3. Subsequent members can be found by advancing the pointer * 0077
*(length of current member + 2 bytes) forward.  These members * 0078
*will also be formatted as <2 byte length>.  * 0079
*Again, it is important to note that the data section starts 2* 0080
*bytes past the beginning of the member.  * 0081
* 4. The number of members in the repeating group will be held in * 0082
*the corresponding 'number of data sections' field in the * 0083
*self-defining section.   * 0084
* * 0085


-Original Message-
From: IBM Mainframe Discussion 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 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

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

Re: Odd SMF 30 data within IEFACTRT

[DanD]

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

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

Re: Odd SMF 30 data within IEFACTRT

[Barry Merrill]

It is documented for many newer SMF records that the COUNT field is the
sole indicator that there are in fact these segments in this record.
The OFFSET seems always to be busy, and the value of the location of
the next triplet, even when this is the last triplet.

As noted, the Length value of zero is now used to indicate that the
actual length is in the first two bytes at the offsed, if COUNT is
non-zero.

Barry


Merrilly yours,

 Herbert W. Barry Merrill, PhD
 President-Programmer
 Merrill Consultants
 MXG Software
 10717 Cromwell Drive  technical questions: supp...@mxg.com
 Dallas, TX 75229
 http://www.mxg.comadmin questions: ad...@mxg.com
 tel: 214 351 1966
 fax: 214 350 3694



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-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 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

--
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: Odd SMF 30 data within IEFACTRT

[Charles Mills]

Here is the offset, here is the (fixed, never any different) length, and here 
is how many of them there are: as it happens, zero.

For many triplets you need to process that count anyway as it may be greater 
than one. 

It's one of those things. It may not make sense to you, but it's the way 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 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? ;-)

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

Re: Odd SMF 30 data within IEFACTRT

[DanD]

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

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

Re: Odd SMF 30 data within IEFACTRT

[Martin Packer]

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  wrote:
> 
> 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
> 
> --
> 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: Odd SMF 30 data within IEFACTRT

[Charles Mills]

You have to check all three fields of the triplet for zero (at least if your 
logic is to work across many SMF record types -- perhaps checking offset & 
count is adequate for SMF 30). Any one of them zero indicates no data.

Except! For DB2 SMF, where a zero length indicates the sections are of variable 
length, each prefixed by a 16-bit length field.

Also, some SMF records use a triplet count or last triplet field somewhere 
around +X'20'. Exact fields in the SMF doc. You need to check that to make sure 
your triplet is there at all.

This is why we get the big bucks ...

Charles


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

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

Re: Odd SMF 30 data within IEFACTRT

[DanD]

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

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

Re: Odd SMF 30 data within IEFACTRT

[Daniel S. Dalby]

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 Section 
ARR15,R5  A(Current Section)   
ARR1,R15  A(SMF Field) 

I'll have to examine the SMF record that I'm processing to see what's messing 
up.

Thanks again
Dan

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

Re: Odd SMF 30 data within IEFACTRT

[Martin Packer]

Right; The pair of DD names gives that away.

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:   Steve Smith <sasd...@gmail.com>
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   06/11/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 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

On Mon, Nov 6, 2017 at 1:14 AM, Mario Bezzi <mbe...@tiscali.it> wrote:
>   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 looking at various data available within the
> IEFACTRT exit's SMF 30 record.

--
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: Odd SMF 30 data within IEFACTRT

[Steve Smith]

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

On Mon, Nov 6, 2017 at 1:14 AM, Mario Bezzi  wrote:
>   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 looking at various data available within the
> IEFACTRT exit's SMF 30 record.

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

Re: Odd SMF 30 data within IEFACTRT

[Mario Bezzi]

  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 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". 
> Here are the fields in the
section and their HEX values: 
> SMF30_US_ComprReq 200F2A40E2E3C5D7 
>
SMF30_US_ComprReq_Prob D3C9C249 
> SMF30_US_QueueTime
7FF8 
> SMF30_US_ExecTime 7FF8 
>
SMF30_US_Def_UncomprIn E2E8E2D7D9C9 
> SMF30_US_Def_ComprOut
D5E3 
> SMF30_US_Inf_ComprIn  
>
SMF30_US_Inf_DecomprOut 200F2A3F 
> 
> The EXECTime and
QueueTime are supposed to be in microseconds. 
> Why does one have
"7FF8" in the 1st word and the other have it in the 2nd word? 
>
ComprReq is the total number of compressions & decompressions (problem
and supervisor state). 
> ComprReq_Prob is the number in problem state.
Shouldn't it be a subset of ComprReq? 
> 
> I'm not sure what other
fields are incorrect. Does anyone else find these odd or is it just me?

> 
> Thanks, 
> Dan 
> 
>
--

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


Con Mobile Open 7 GB a 9 euro/4 sett navighi veloce con 7 GB di Internet e hai 
200 minuti ed SMS a 12 cent. Passa a Tiscali Mobile! 
http://tisca.li/OPEN7GBFirma


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

Re: Odd SMF 30 data within IEFACTRT

[DanD]

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

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

Re: Odd SMF 30 data within IEFACTRT

[Lizette Koehler]

Are you using the IEFACTRT shipped by IBM in SYS1.SAMPLIB or a different 
version?

If the IBM version, when was the last time you assembled and linked IBM's 
version.  If it has been a while, I might suggest you get a fresh copy and see 
what it looks like compared to what you are seeing.

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 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".
> Here are the fields in the section and their HEX values:
> SMF30_US_ComprReq 200F2A40E2E3C5D7
> SMF30_US_ComprReq_Prob D3C9C249
> SMF30_US_QueueTime7FF8
> SMF30_US_ExecTime   7FF8
> SMF30_US_Def_UncomprIn  E2E8E2D7D9C9
> SMF30_US_Def_ComprOut   D5E3
> SMF30_US_Inf_ComprIn  
> SMF30_US_Inf_DecomprOut200F2A3F
> 
> The EXECTime and QueueTime are supposed to be in microseconds.
> Why does one have "7FF8" in the 1st word and the other have it in the 2nd
> word?
> ComprReq is the total number of compressions & decompressions (problem and
> supervisor state).
> ComprReq_Prob is the number in problem state.  Shouldn't it be a subset of
> ComprReq?
> 
> I'm not sure what other fields are incorrect.  Does anyone else find these
> odd or is it just me?
> 
> Thanks,
> Dan
> 

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