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
