The RMF Work Delay monitor (monitor3) can show you why each task is delayed, and what resource is holding it up eg /f rmf,start III TSO RMFWDM option *2* (2 JOBS All information about job delays Enter your TSO userid selection 8 for delays by processor
or go back to home screen, 3 resources, 1/1a for processor delays or option PD or PU it samples the syste, over about a minute or two. Colin On Mon, 7 Aug 2023 at 13:53, Allan Staller < [email protected]> wrote: > Classification: Confidential > > In that case, either the capacity (or weight) of the LPAR will need to be > increased, or as another suggested, give access to another CP. > The only other thing you can do is get with the DB2 folks to see if they > can do something with the restore process. > > HTH, > > -----Original Message----- > From: IBM Mainframe Discussion List <[email protected]> On Behalf > Of rpinion865 > Sent: Monday, August 7, 2023 7:34 AM > To: [email protected] > Subject: Re: z/OS performance question > > [CAUTION: This Email is from outside the Organization. Unless you trust > the sender, Don’t click links or open attachments as it may be a Phishing > email, which can steal your Information and compromise your Computer.] > > While adjusting the WLM definitions might help TSO, I would like to add > that I put my TSO userid in SYSSTC. Even running in that service class my > TSO response is sluggish. > > > > > Sent with Proton Mail secure email. > > ------- Original Message ------- > On Monday, August 7th, 2023 at 8:30 AM, Allan Staller < > [email protected]> wrote: > > > > Classification: Confidential > > > > Ok. You zre using 2 period TSO Service Defs. I suggest you adjust the > period 1 duration until 96% (vs. 90%) of transactions end in period one. > > There is no easy way to measure this in advance. The RMF Service Class > Period report will however show the results after the fact. > > > > Increase the duration of period one and look at the RM report. Wash, > rinse, repeat until the desired goal is achieved. Beyond that, I do not > believe there can be much done. IIRC the DB2MSTR address space either runs > at IMP 1 or in the SYSSTC service class. > > > > Speculating (I am not a DB2 expert) if commits can be take during the > restore, it might help. > > > > Wish I could help more. > > > > > > > > > > -----Original Message----- > > From: IBM Mainframe Discussion List [email protected] On Behalf > > Of rpinion865 > > > > Sent: Friday, August 4, 2023 12:12 PM > > To: [email protected] > > Subject: Re: z/OS performance question > > > > [CAUTION: This Email is from outside the Organization. Unless you > > trust the sender, Don’t click links or open attachments as it may be a > > Phishing email, which can steal your Information and compromise your > > Computer.] > > > > I am working with the Development LPAR (SC08D3). Below is the TSO > service class definition for that LPAR. > > > > Service Class Name . . . . . : TSOSC > > > > Description . . . . . . . . . TSO Production and Development > > > > Workload Name . . . . . . . . TSO (name or ?) > > > > Base Resource Group . . . . . ________ (name or ?) > > > > Cpu Critical . . . . . . . . . NO (YES or NO) > > > > I/O Priority Group . . . . . . NORMAL (NORMAL or HIGH) > > > > Honor Priority . . . . . . . . DEFAULT (DEFAULT or NO) > > > > > > > > Specify BASE GOAL information. Action Codes: I=Insert new period, > > > > E=Edit period, D=Delete period. > > > > > > > > -- Period -- ------------------- Goal ------------------- > > > > Action # Duration Imp. Description > > > > __ _ _________ _ ________________________________________ > > > > __ 1 500 1 90% complete within 00:00:00.060 > > > > __ 2 _________ 4 Execution velocity of 40 > > > > Next, is a mangled text view of the Development (SC08D3) LPAR definition. > > Customize Image Profiles: Z15A:SC08D3 : SC08D3 : Processor Turn on > context sensitive help. > > Collapse Z15A:SC08D3 > > Collapse SC08D3 > > General > > Processor > > Security > > Storage > > Options > > Load > > Crypto > > Group Name > > > > <Not Assigned> > > > > Open or close the list box > > Logical Processor Assignments > > Dedicated processors > > Select > > Processor Type > > Initial > > Reserved > > Selected > > Central processors (CPs) > > 1 > > 0 > > Selected > > z Integrated Information Processors (zIIPs) > > 1 > > 0 > > Not Dedicated Processor Details for: > > CPs > > zIIPs > > CP Details > > Initial processing weight > > 60 > > 1 to 999 > > Initial capping > > Enable workload manager > > Minimum processing weight > > 0 > > Maximum processing weight > > 0 > > Absolute Capping > > None > > Number of processors > > (0.01 to 255.0) > > 0.18 > > > > > > > > > > > > Sent with Proton Mail secure email. > > > > > > ------- Original Message ------- > > On Thursday, August 3rd, 2023 at 12:17 PM, Allan Staller > [email protected] wrote: > > > > > > > > > Classification: Confidential > > > > > > You did not say where the TSO response time issues were being > observed. I suspect, from the information provided it is on > SC08D3(possible) or SC14D4 (most likely). > > > > > > If you look, I suspect the majority of CPU consumption is from the > *MSTR DB2 address space. DB2 will charge this back to the "user". This > address space is most likely running in the SYSSTC Service class. > > > > > > I suggest you look at the service class definitions for TSO. At least > 80% of all transactions should end in TSO Service Class Period 1, 80 % of > the rest in TSO Service Class Period 2 (16%) and the remainder in TSO > Service Class period 3 (4 %). Another variation could be TSO Service Class > Period 1 at 96% and TSO Service Class Period 2 4%; No TSO Service Class > Period 3. > > > > > > Depending on the scheme chosen above, except for the last TSO Service > Class, all should run as importance 1. They may have different performance > goals, but the importance should be 1. > > > > > > " From the activation profile for Development (SC08D3) the Processor > definition has the absolute Capping box Number of processors box set to > 0.18.”. This sentence does not make sense as written. > > > > > > HTH, > > > > > > -----Original Message----- > > > From: IBM Mainframe Discussion List [email protected] On > > > Behalf Of rpinion865 > > > > > > Sent: Thursday, August 3, 2023 10:10 AM > > > To: [email protected] > > > Subject: z/OS performance question > > > > > > [CAUTION: This Email is from outside the Organization. Unless you > > > trust the sender, Don’t click links or open attachments as it may be > > > a Phishing email, which can steal your Information and compromise > > > your Computer.] > > > > > > Let me start off by saying I am not a z/OS performance and capacity > planning expert. If anything, I am a novice. I am looking for a trivial > answer to a non-trivial question. > > > We have a z15 (8562-T02) running three z/OS 2.4 LPAR's, Production > (SC10D1), Development (SC08D3), and Sysprog (SC14D4). Below is information > from the RMF Partition Report. My question/problem is this. On the > Development LPAR, when a DB2 database restore job runs, the MVS Busy goes > to 100% as seen from both SDSF DA and RMF CPU reports. Most of the CPU Busy > goes to the DB2 restore job. The batch job runs in a discretionary service > class, and TSO users run in a higher service class with goal mode. But, > response time for the TSO users gets long, 3 to 5 seconds between enter > keys, ISPF screen swaps etc.. Normally the TSO response time is sub-second. > As you can see, the Development LPAR has one Logical CP defined. Based on > the capping characteristics of Development as displayed below, would adding > another Logical CP help TSO response time? > > > > > > 1 P A R T I T I O N D A T A R E P O R T PAGE 3 z/OS V2R4 SYSTEM ID > > > SC10 DATE 08/01/2023 INTERVAL 14.59.992 RPT VERSION V2R4 RMF TIME > > > 05.45.00 CYCLE 1.000 SECONDS > > > - > > > MVS PARTITION NAME SC10D1 PHYS PROC NUM 5 LP GROUP NAME N/A INITIAL > > > CAP NO IMAGE CAPACITY 138 CP 2 2 LIMIT N/A LPAR HW CAP NO NUMBER OF > > > CONFIGURED PARTITIONS 5 ICF 1 AVAILABLE N/A HW GROUP CAP NO WAIT > > > COMPLETION NO IIP 2 2 ABS MSU CAP NO DISPATCH INTERVAL DYNAMIC > > > > > > MVS PARTITION NAME SC08D3 PHYS PROC NUM 5 LP GROUP NAME N/A INITIAL > > > CAP NO IMAGE CAPACITY 10 CP 2 1 LIMIT N/A LPAR HW CAP YES NUMBER OF > > > CONFIGURED PARTITIONS 5 ICF 1 AVAILABLE N/A HW GROUP CAP NO WAIT > > > COMPLETION NO IIP 2 1 ABS MSU CAP NO DISPATCH INTERVAL DYNAMIC > > > - > > > ------------ PARTITION DATA ------------------ > > > ----MSU---- --CAPPING--- > > > NAME S BT WGT DEF ACT DEF WLM% NUM TYPE > > > SC10D1 A N 999 138 27 N N N 0.0 2.0 CP > > > SC08D3 A N 60 10 3 N Y N 0.0 1.0 CP (1) > > > SC14D4 A N 18 4 2 N N N 0.0 1.0 CP > > > TOTAL 1077 > > > > > > - From the activation profile for Development (SC08D3) the Processor > definition has the absolute Capping box Number of processors box set to > 0.18. > > > > > > -------------------------------------------------------------------- > > > -- For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to [email protected] with the message: INFO > > > IBM-MAIN > > > ::DISCLAIMER:: > > > ________________________________ > > > The contents of this e-mail and any attachment(s) are confidential and > intended for the named recipient(s) only. E-mail transmission is not > guaranteed to be secure or error-free as information could be intercepted, > corrupted, lost, destroyed, arrive late or incomplete, or may contain > viruses in transmission. The e mail and its contents (with or without > referred errors) shall therefore not attach any liability on the originator > or HCL or its affiliates. Views or opinions, if any, presented in this > email are solely those of the author and may not necessarily reflect the > views or opinions of HCL or its affiliates. Any form of reproduction, > dissemination, copying, disclosure, modification, distribution and / or > publication of this message without the prior written consent of authorized > representative of HCL is strictly prohibited. If you have received this > email in error please delete it and notify the sender immediately. Before > opening any email and/or attachments, please check them for viruses and > other defects. > > > ________________________________ > > > > > > -------------------------------------------------------------------- > > > -- For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to [email protected] with the message: INFO > > > IBM-MAIN > > > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, send > > email to [email protected] with the message: INFO IBM-MAIN > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, send > > email to [email protected] with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to [email protected] with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
