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
