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
