Take a look at RMF Monitor III reports taken during intervals of TSO activity. What is the performance index for your TSO service class periods? What are the delay percentages for your TSO users' address spaces?
-----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Allan Staller Sent: Monday, August 7, 2023 8:53 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: z/OS performance question CAUTION! This email originated outside of the organization. Please do not open attachments or click links from an unknown or suspicious origin. ====================================================================== 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 <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of rpinion865 Sent: Monday, August 7, 2023 7:34 AM To: IBM-MAIN@LISTSERV.UA.EDU 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 <00000387911dea17-dmarc-requ...@listserv.ua.edu> 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 IBM-MAIN@LISTSERV.UA.EDU On Behalf > Of rpinion865 > > Sent: Friday, August 4, 2023 12:12 PM > To: IBM-MAIN@LISTSERV.UA.EDU > 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 > 00000387911dea17-dmarc-requ...@listserv.ua.edu 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 IBM-MAIN@LISTSERV.UA.EDU On > > Behalf Of rpinion865 > > > > Sent: Thursday, August 3, 2023 10:10 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > 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 lists...@listserv.ua.edu 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 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 > > ---------------------------------------------------------------------- > 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 ---------------------------------------------------------------------- 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
