Re: z/OS performance question
Sorry I forgot to mention, the Development LPAR has access to a ZIIP. Sent with Proton Mail secure email. --- Original Message --- On Friday, August 11th, 2023 at 11:34 AM, Jon Butler wrote: > Depending on the actual work characteristics, you might consider buying a > zIIP. You could share this between PROD and DEV to offload a lot of "grunt" > work that runs in an SRB, including Sorts and many ISV products from BMC and > Broadcom. More good news, any work offloaded from the GPs may cut your MLC > charges. > > -- > 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
Re: z/OS performance question
Depending on the actual work characteristics, you might consider buying a zIIP. You could share this between PROD and DEV to offload a lot of "grunt" work that runs in an SRB, including Sorts and many ISV products from BMC and Broadcom. More good news, any work offloaded from the GPs may cut your MLC charges. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS performance question
Additional update on our configuration. We have a z15-T02, with two physical engines. Our production LPAR has one dedicated GCP and shares the second GCP with the Development LPAR. Since Development only has access to only one physical processor, our performance and tuning company feels that adding another logical GCP would not help. They have pointed out that the DB2 work coming from the DB2 batch jobs, may be generating SRBs, which are always dispatched before TCBs and due to the capping, TSO and other work gets delayed. Sent with Proton Mail secure email. --- Original Message --- On Wednesday, August 9th, 2023 at 11:02 PM, Graham Harris wrote: > I have seen Db2 unloads use vastly more (overall total) CPU when doing > parallelised processing, compared to non-parallelised. > Obviously you are doing reload (I presume) rather than unload, but the same > thing may apply. > So might be something worth checking/testing, if parallelism is relevant to > your situation. Not just for the overall CPU aspect (which was never > determined as to whether it was an actual bug or not, as far as I > remember), but also with regard to the numerous threads that would be > trying to dispatch simultaneously, and the contention that would generate > on a single CP LPAR. > > On Wed, 9 Aug 2023 at 17:06, rpinion865 < > 042a019916dd-dmarc-requ...@listserv.ua.edu> wrote: > > > Well, for starters the DB2 address spaces are in a service class named > > STCHI, which has the following WLM definitions. > > Importance Level 1 with an execution velocity of 55. Regarding the > > situation when "DB2" uses most of the CPU. It is > > not the DB2 address spaces that max out the CPU, rather the batch jobs > > using DB2, in this case a batch job to restore > > a database. We have a third party who does our performance management and > > makes recommendations. We have asked them > > to look at the DB2 batch jobs. One comment they made was that the > > database restore may be invoking internal sorts, > > with little I/O interrupts. Therefore allowing this batch job, with the > > related WLM controls, to dominate the CPU. > > > > Which is why I think adding another logical CP to the LPAR would help > > other work. What we have to be very careful > > about is not to increase the MSU usage of this LPAR. We run several IBM > > and non-IBM products on this LPAR that have > > their pricing based on the capped MSU usage for this LPAR. > > > > Sent with Proton Mail secure email. > > > > --- Original Message --- > > On Wednesday, August 9th, 2023 at 11:24 AM, Rebecca Martin < > > 050348c1817e-dmarc-requ...@listserv.ua.edu> wrote: > > > > > By any chance do you have your Db2 address spaces in SYSSTC? If yes, get > > > them moved out AND share give development uses of both logical CPs. > > > IRLM should be there but the others should. On a 1 CP system, all > > > regular work stops while a task in SYSSTC is using the CPU. High CPU users > > > like Db2 should not be in SYSSTC; especially on a system with only 1 > > > logical CP. > > > > > > -- > > > 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
Re: z/OS performance question
I have seen Db2 unloads use vastly more (overall total) CPU when doing parallelised processing, compared to non-parallelised. Obviously you are doing reload (I presume) rather than unload, but the same thing may apply. So might be something worth checking/testing, if parallelism is relevant to your situation. Not just for the overall CPU aspect (which was never determined as to whether it was an actual bug or not, as far as I remember), but also with regard to the numerous threads that would be trying to dispatch simultaneously, and the contention that would generate on a single CP LPAR. On Wed, 9 Aug 2023 at 17:06, rpinion865 < 042a019916dd-dmarc-requ...@listserv.ua.edu> wrote: > Well, for starters the DB2 address spaces are in a service class named > STCHI, which has the following WLM definitions. > Importance Level 1 with an execution velocity of 55. Regarding the > situation when "DB2" uses most of the CPU. It is > not the DB2 address spaces that max out the CPU, rather the batch jobs > using DB2, in this case a batch job to restore > a database. We have a third party who does our performance management and > makes recommendations. We have asked them > to look at the DB2 batch jobs. One comment they made was that the > database restore may be invoking internal sorts, > with little I/O interrupts. Therefore allowing this batch job, with the > related WLM controls, to dominate the CPU. > > Which is why I think adding another logical CP to the LPAR would help > other work. What we have to be very careful > about is not to increase the MSU usage of this LPAR. We run several IBM > and non-IBM products on this LPAR that have > their pricing based on the capped MSU usage for this LPAR. > > > > > Sent with Proton Mail secure email. > > --- Original Message --- > On Wednesday, August 9th, 2023 at 11:24 AM, Rebecca Martin < > 050348c1817e-dmarc-requ...@listserv.ua.edu> wrote: > > > > By any chance do you have your Db2 address spaces in SYSSTC? If yes, get > them moved out AND share give development uses of both logical CPs. > > IRLM should be there but the others should. On a 1 CP system, all > regular work stops while a task in SYSSTC is using the CPU. High CPU users > like Db2 should not be in SYSSTC; especially on a system with only 1 > logical CP. > > > > -- > > 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
Re: z/OS performance question
Well, for starters the DB2 address spaces are in a service class named STCHI, which has the following WLM definitions. Importance Level 1 with an execution velocity of 55. Regarding the situation when "DB2" uses most of the CPU. It is not the DB2 address spaces that max out the CPU, rather the batch jobs using DB2, in this case a batch job to restore a database. We have a third party who does our performance management and makes recommendations. We have asked them to look at the DB2 batch jobs. One comment they made was that the database restore may be invoking internal sorts, with little I/O interrupts. Therefore allowing this batch job, with the related WLM controls, to dominate the CPU. Which is why I think adding another logical CP to the LPAR would help other work. What we have to be very careful about is not to increase the MSU usage of this LPAR. We run several IBM and non-IBM products on this LPAR that have their pricing based on the capped MSU usage for this LPAR. Sent with Proton Mail secure email. --- Original Message --- On Wednesday, August 9th, 2023 at 11:24 AM, Rebecca Martin <050348c1817e-dmarc-requ...@listserv.ua.edu> wrote: > By any chance do you have your Db2 address spaces in SYSSTC? If yes, get them > moved out AND share give development uses of both logical CPs. > IRLM should be there but the others should. On a 1 CP system, all regular > work stops while a task in SYSSTC is using the CPU. High CPU users like Db2 > should not be in SYSSTC; especially on a system with only 1 logical CP. > > -- > 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
Re: z/OS performance question
By any chance do you have your Db2 address spaces in SYSSTC? If yes, get them moved out AND share give development uses of both logical CPs. IRLM should be there but the others should. On a 1 CP system, all regular work stops while a task in SYSSTC is using the CPU. High CPU users like Db2 should not be in SYSSTC; especially on a system with only 1 logical CP. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS performance question
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 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 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 <0387911dea17-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 > > > > 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
Re: z/OS performance question
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 JOBSAll 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 < 0387911dea17-dmarc-requ...@listserv.ua.edu> 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 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 < > 0387911dea17-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 > > > > > > > > Open or close the list box > > Logical Processor Assignments > > Dedicated processors > > Select > > Processor Type > > Initial > > Reserved > > Selected > > Central processors (CPs) > > 1 > > 0 > >
Re: z/OS performance question
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 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 <0387911dea17-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 > > > > 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 > 0387911dea17-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 ad
Re: z/OS performance question
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 <0387911dea17-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 > > > > 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 > 0387911dea17-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 differen
Re: z/OS performance question
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 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 190% complete within 00:00:00.060 __2 _ 4Execution 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 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 <0387911dea17-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
Re: z/OS performance question
You can get by with 1 logical cp on the sandbox but, I would still want 2. For a development LPAR with Db2, you need the 2 logical CPs. Has it always been restricted to 1 CP? If not, why was it changed? Everything on that LPAR will perform better with 2 CPs compared to 1 CP. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS performance question
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 190% complete within 00:00:00.060 __2 _ 4Execution 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 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 <0387911dea17-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
Re: z/OS performance question
Check all the DB2 address spaces. What may be happening is something like 1. Restore job reads a record, and calls DB2 to update the database, reads next record calls db2... 2. DB2 buffer pools start filling up, so DB2 starts writing data out to the page sets 3. DB2 may also be doing things like read ahead... so if it does a read before update it is in the buffer pool. This also takes CPU So overall DB2 may be using a lot of CPU Try Allan's advice for the service classes. With service classes, you only find that they are not configured optimally when they LPAR is short of CPU, and they get used. On Thu, 3 Aug 2023 at 17:18, Allan Staller < 0387911dea17-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 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
Re: z/OS performance question
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 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 vi
z/OS performance question
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
Re: z/OS performance question
Thanks, everyone. We are running z/OS v2.1, just upgraded from z/OS v1.12. Over the weekend, I add a second structure to the CLASSDEF SML. Hopefully, that will help with the issues. Thanks again, Jerry From: IBM Mainframe Discussion List on behalf of Michael Babcock Sent: Sunday, May 3, 2020 12:43 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS performance question This message was sent from an external source outside of Western & Southern's network. Do not click links or open attachments unless you recognize the sender and know the contents are safe. If you are on z/OS 2.4 you don’t need to tune the classes. Just turn on auto tuning. On Fri, May 1, 2020 at 1:44 PM Edgington, Jerry < jerry.edging...@westernsouthernlife.com> wrote: > Thanks Allen, that is good place to start. The CPU% for the ISGLOCK, > IXCSTR1 and IXCSTR2 are 58%, 74% and 21%, which seem very high to me. But, > the IXCSTR3 and IXCSTR4 are very low. It would seem I might have an > imbalance with the XCF messages and size. Async rate for IXCSTR1 is 120 > > I am wondering if I need to adjust my CLASSDEF CLASSLEN size for each of > the structures. We are running ICFs on GP, with one virtual connection to > each ICFA/B. Not ideal, but all I could do at the moment. > > > /* TRANSPORT CLASSES. */ > CLASSDEF CLASS(SML) CLASSLEN(956) GROUP(UNDESIG) > CLASSDEF CLASS(MED) CLASSLEN(8000) > CLASSDEF CLASS(DEFAULT) CLASSLEN(16316) > CLASSDEF CLASS(BIG) CLASSLEN(32000) > > /* XCF STRUCTURES */ > PATHOUT STRNAME(IXCSTR1) CLASS(SML) > PATHOUT STRNAME(IXCSTR2) CLASS(MED) > PATHOUT STRNAME(IXCSTR3) CLASS(BIG) > PATHOUT STRNAME(IXCSTR4) CLASS(DEFAULT) > /* */ > PATHIN STRNAME(IXCSTR1,IXCSTR2,IXCSTR3,IXCSTR4) > > Also, we have: > FUNCTIONS ENABLE(DUPLEXCF16, SYSSTATDETECT, CRITICALPAGING) > > Thanks Jerry > > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Allan Staller > Sent: Friday, May 1, 2020 2:32 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: z/OS performance question > > This message was sent from an external source outside of Western & > Southern's network. Do not click links or open attachments unless you > recognize the sender and know the contents are safe. > > > > The only tuning I a aware of for XCF is to provide appropriate transport > classes for the messages being passed. If inappropriate, this will usually > show up as CPU concumption in the XCFAS address space. Look at the CPU > consumed, not the delay. > > It is possible that this is contributing to the CICS delays. GRS will use > XCF if available. > > -Original Message----- > From: IBM Mainframe Discussion List On Behalf > Of Edgington, Jerry > Sent: Friday, May 1, 2020 12:30 PM > 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.] > > To anyone, > > I am not a performance person at all, but can someone help me with > pointing me in the right direction. We are running a small SYSplex, but we > are getting delays on one LPAR, PROC-XCFAS > > *SYSTEMPROC-XCFAS 3.7 users > ALL STCPROC-XCFAS 3.2 users > IMS PROC-XCFAS 26.0 % delay > RMFPROC-XCFAS 18.0 % delay > RMFGAT PROC-XCFAS 21.0 % delay > IMSCTL PROC-XCFAS 25.0 % delay > TN3270 PROC-XCFAS 28.0 % delay > VTAM PROC-XCFAS 19.0 % delay > > Also, we are ACF2 shop and our production CICS regions are getting delays: > > ENQ -ACFVSAM 38.0 % delay LOGONIDS > ENQ -ACF2ACB 100.0 % delay LOGONIDS > > So any help would be great. > Thanks, > Jerry Edgington > > -- > 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 cont
Re: z/OS performance question
If you are on z/OS 2.4 you don’t need to tune the classes. Just turn on auto tuning. On Fri, May 1, 2020 at 1:44 PM Edgington, Jerry < jerry.edging...@westernsouthernlife.com> wrote: > Thanks Allen, that is good place to start. The CPU% for the ISGLOCK, > IXCSTR1 and IXCSTR2 are 58%, 74% and 21%, which seem very high to me. But, > the IXCSTR3 and IXCSTR4 are very low. It would seem I might have an > imbalance with the XCF messages and size. Async rate for IXCSTR1 is 120 > > I am wondering if I need to adjust my CLASSDEF CLASSLEN size for each of > the structures. We are running ICFs on GP, with one virtual connection to > each ICFA/B. Not ideal, but all I could do at the moment. > > > /* TRANSPORT CLASSES. */ > CLASSDEF CLASS(SML) CLASSLEN(956) GROUP(UNDESIG) > CLASSDEF CLASS(MED) CLASSLEN(8000) > CLASSDEF CLASS(DEFAULT) CLASSLEN(16316) > CLASSDEF CLASS(BIG) CLASSLEN(32000) > > /* XCF STRUCTURES */ > PATHOUT STRNAME(IXCSTR1) CLASS(SML) > PATHOUT STRNAME(IXCSTR2) CLASS(MED) > PATHOUT STRNAME(IXCSTR3) CLASS(BIG) > PATHOUT STRNAME(IXCSTR4) CLASS(DEFAULT) > /* */ > PATHIN STRNAME(IXCSTR1,IXCSTR2,IXCSTR3,IXCSTR4) > > Also, we have: > FUNCTIONS ENABLE(DUPLEXCF16, SYSSTATDETECT, CRITICALPAGING) > > Thanks Jerry > > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Allan Staller > Sent: Friday, May 1, 2020 2:32 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: z/OS performance question > > This message was sent from an external source outside of Western & > Southern's network. Do not click links or open attachments unless you > recognize the sender and know the contents are safe. > > > > The only tuning I a aware of for XCF is to provide appropriate transport > classes for the messages being passed. If inappropriate, this will usually > show up as CPU concumption in the XCFAS address space. Look at the CPU > consumed, not the delay. > > It is possible that this is contributing to the CICS delays. GRS will use > XCF if available. > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Edgington, Jerry > Sent: Friday, May 1, 2020 12:30 PM > 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.] > > To anyone, > > I am not a performance person at all, but can someone help me with > pointing me in the right direction. We are running a small SYSplex, but we > are getting delays on one LPAR, PROC-XCFAS > > *SYSTEMPROC-XCFAS 3.7 users > ALL STCPROC-XCFAS 3.2 users > IMS PROC-XCFAS 26.0 % delay > RMFPROC-XCFAS 18.0 % delay > RMFGAT PROC-XCFAS 21.0 % delay > IMSCTL PROC-XCFAS 25.0 % delay > TN3270 PROC-XCFAS 28.0 % delay > VTAM PROC-XCFAS 19.0 % delay > > Also, we are ACF2 shop and our production CICS regions are getting delays: > > ENQ -ACFVSAM 38.0 % delay LOGONIDS > ENQ -ACF2ACB 100.0 % delay LOGONIDS > > So any help would be great. > Thanks, > Jerry Edgington > > -- > 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. >
Re: z/OS performance question
And how about LPAR effects for the coupled z/OS images? If starved for CPU presumably all this can go South very fast. (This is certainly true when we’re talking about CF so is probably true - whether CTCs or CF structures - with XCF. Cheers, Martin Sent from my iPad > On 2 May 2020, at 22:28, Mark A. Brooks wrote: > > So you have only one signal structure per transport class? If your traffic is like most, the small traffic is an order of magnitude more than any other size, and it's all flowing to the same place. Each target system will have a unique list, so you get some distribution from that. But if you have high signals/sec to a given target, you may be getting some latch contention within the CF (but it all depends). Fussing with the transport class definitions will not help. If all else was well, I'd be looking to add another signal structure to the SML class. If you can't do a 5th structure, then I might consider revamping the classdefs so that I could reassign one of the other 3 structures to SML. > > However, it's not clear to me what your configuration is. I'm wondering if you are having path busy or subchannel busy conditions. Or perhaps shared engines for the CF. Just the one GP for the CF? Just the one CF? Those sorts of issues should be addressed first. What type of machine? Signal rates? > > Last I knew, the RMF %delay was based on periodic sampling, perhaps every second. They look at what XCF reports as "pending signals". If for example, 10 samples out of 100 catch XCF with a pending signal, they'd report 10% delay. So what's a pending signal? It's a signal whose send I/O has not yet completed and it's been at least a millisecond since the signal was accepted for delivery. If we assume there is nothing "funny", such as path restart or structure rebuild, then a signal is pending either because the signal is waiting for the I/O to be started (so we have queueing delay) or the I/O was started and we're waiting for the back end completion to run. You said "Async rate for IXCSTR1 is 120", by which I assume you mean average response time for the IXCSTR1 requests is 120 mics (as opposed to 120 requests/second). The standard deviation will give you a sense of the variation in the waiting for the async back end completion to run. But let's say 120 is the number. If your workload sends a burst of 20 small signals a millisecond before RMF takes their sample, you'll see %delay (XCF sends signals in batches of 4, 120 mics per batch, the 5th batch will be seen as pending). If that's the pattern, then even at 100% delay, I dare say your workload is not suffering in the least. > > So whenever RMF reports %delay for XCF, you have to go see if the XCF signal path activity reports are showing any signs of queueing. What is AVG Q LEN? What is AVAIL vs BUSY? AVG Q LEN is usually zero or close to it. I tend to be unconcerned until it becomes more than one. BUSY tends to suggest that the batches are backing up. Adding another signal path helps address both AVG Q LEN and high BUSY conditions. HOWEVER, one should always look to address factors that can contribute to these conditions: "no buffer" conditions on the inbound side, or path busy, subchannel busy delays for the CF. > > > Mark A Brooks > z/OS Sysplex Development > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS performance question
Wow, thanks Mark. this is great. From: IBM Mainframe Discussion List on behalf of Mark A. Brooks Sent: Saturday, May 2, 2020 5:27 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS performance question This message was sent from an external source outside of Western & Southern's network. Do not click links or open attachments unless you recognize the sender and know the contents are safe. So you have only one signal structure per transport class? If your traffic is like most, the small traffic is an order of magnitude more than any other size, and it's all flowing to the same place. Each target system will have a unique list, so you get some distribution from that. But if you have high signals/sec to a given target, you may be getting some latch contention within the CF (but it all depends). Fussing with the transport class definitions will not help. If all else was well, I'd be looking to add another signal structure to the SML class. If you can't do a 5th structure, then I might consider revamping the classdefs so that I could reassign one of the other 3 structures to SML. However, it's not clear to me what your configuration is. I'm wondering if you are having path busy or subchannel busy conditions. Or perhaps shared engines for the CF. Just the one GP for the CF? Just the one CF? Those sorts of issues should be addressed first. What type of machine? Signal rates? Last I knew, the RMF %delay was based on periodic sampling, perhaps every second. They look at what XCF reports as "pending signals". If for example, 10 samples out of 100 catch XCF with a pending signal, they'd report 10% delay. So what's a pending signal? It's a signal whose send I/O has not yet completed and it's been at least a millisecond since the signal was accepted for delivery. If we assume there is nothing "funny", such as path restart or structure rebuild, then a signal is pending either because the signal is waiting for the I/O to be started (so we have queueing delay) or the I/O was started and we're waiting for the back end completion to run. You said "Async rate for IXCSTR1 is 120", by which I assume you mean average response time for the IXCSTR1 requests is 120 mics (as opposed to 120 requests/second). The standard deviation will give you a sense of the variation in the waiting for the async back end completion to run. But let's say 120 is the number. If your workload sends a burst of 20 small signals a millisecond before RMF takes their sample, you'll see %delay (XCF sends signals in batches of 4, 120 mics per batch, the 5th batch will be seen as pending). If that's the pattern, then even at 100% delay, I dare say your workload is not suffering in the least. So whenever RMF reports %delay for XCF, you have to go see if the XCF signal path activity reports are showing any signs of queueing. What is AVG Q LEN? What is AVAIL vs BUSY? AVG Q LEN is usually zero or close to it. I tend to be unconcerned until it becomes more than one. BUSY tends to suggest that the batches are backing up. Adding another signal path helps address both AVG Q LEN and high BUSY conditions. HOWEVER, one should always look to address factors that can contribute to these conditions: "no buffer" conditions on the inbound side, or path busy, subchannel busy delays for the CF. Mark A Brooks z/OS Sysplex Development -- 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
Re: z/OS performance question
So you have only one signal structure per transport class? If your traffic is like most, the small traffic is an order of magnitude more than any other size, and it's all flowing to the same place. Each target system will have a unique list, so you get some distribution from that. But if you have high signals/sec to a given target, you may be getting some latch contention within the CF (but it all depends). Fussing with the transport class definitions will not help. If all else was well, I'd be looking to add another signal structure to the SML class. If you can't do a 5th structure, then I might consider revamping the classdefs so that I could reassign one of the other 3 structures to SML. However, it's not clear to me what your configuration is. I'm wondering if you are having path busy or subchannel busy conditions. Or perhaps shared engines for the CF. Just the one GP for the CF? Just the one CF? Those sorts of issues should be addressed first. What type of machine? Signal rates? Last I knew, the RMF %delay was based on periodic sampling, perhaps every second. They look at what XCF reports as "pending signals". If for example, 10 samples out of 100 catch XCF with a pending signal, they'd report 10% delay. So what's a pending signal? It's a signal whose send I/O has not yet completed and it's been at least a millisecond since the signal was accepted for delivery. If we assume there is nothing "funny", such as path restart or structure rebuild, then a signal is pending either because the signal is waiting for the I/O to be started (so we have queueing delay) or the I/O was started and we're waiting for the back end completion to run. You said "Async rate for IXCSTR1 is 120", by which I assume you mean average response time for the IXCSTR1 requests is 120 mics (as opposed to 120 requests/second). The standard deviation will give you a sense of the variation in the waiting for the async back end completion to run. But let's say 120 is the number. If your workload sends a burst of 20 small signals a millisecond before RMF takes their sample, you'll see %delay (XCF sends signals in batches of 4, 120 mics per batch, the 5th batch will be seen as pending). If that's the pattern, then even at 100% delay, I dare say your workload is not suffering in the least. So whenever RMF reports %delay for XCF, you have to go see if the XCF signal path activity reports are showing any signs of queueing. What is AVG Q LEN? What is AVAIL vs BUSY? AVG Q LEN is usually zero or close to it. I tend to be unconcerned until it becomes more than one. BUSY tends to suggest that the batches are backing up. Adding another signal path helps address both AVG Q LEN and high BUSY conditions. HOWEVER, one should always look to address factors that can contribute to these conditions: "no buffer" conditions on the inbound side, or path busy, subchannel busy delays for the CF. Mark A Brooks z/OS Sysplex Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS performance question
Given that info, you might also check on the size of the ISGLOCK structure and adjust that if needed. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Edgington, Jerry Sent: Friday, May 1, 2020 1:44 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.] Thanks Allen, that is good place to start. The CPU% for the ISGLOCK, IXCSTR1 and IXCSTR2 are 58%, 74% and 21%, which seem very high to me. But, the IXCSTR3 and IXCSTR4 are very low. It would seem I might have an imbalance with the XCF messages and size. Async rate for IXCSTR1 is 120 I am wondering if I need to adjust my CLASSDEF CLASSLEN size for each of the structures. We are running ICFs on GP, with one virtual connection to each ICFA/B. Not ideal, but all I could do at the moment. /* TRANSPORT CLASSES. */ CLASSDEF CLASS(SML) CLASSLEN(956) GROUP(UNDESIG) CLASSDEF CLASS(MED) CLASSLEN(8000) CLASSDEF CLASS(DEFAULT) CLASSLEN(16316) CLASSDEF CLASS(BIG) CLASSLEN(32000) /* XCF STRUCTURES */ PATHOUT STRNAME(IXCSTR1) CLASS(SML) PATHOUT STRNAME(IXCSTR2) CLASS(MED) PATHOUT STRNAME(IXCSTR3) CLASS(BIG) PATHOUT STRNAME(IXCSTR4) CLASS(DEFAULT) /* */ PATHIN STRNAME(IXCSTR1,IXCSTR2,IXCSTR3,IXCSTR4) Also, we have: FUNCTIONS ENABLE(DUPLEXCF16, SYSSTATDETECT, CRITICALPAGING) Thanks Jerry -Original Message- From: IBM Mainframe Discussion List On Behalf Of Allan Staller Sent: Friday, May 1, 2020 2:32 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS performance question This message was sent from an external source outside of Western & Southern's network. Do not click links or open attachments unless you recognize the sender and know the contents are safe. The only tuning I a aware of for XCF is to provide appropriate transport classes for the messages being passed. If inappropriate, this will usually show up as CPU concumption in the XCFAS address space. Look at the CPU consumed, not the delay. It is possible that this is contributing to the CICS delays. GRS will use XCF if available. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Edgington, Jerry Sent: Friday, May 1, 2020 12:30 PM 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.] To anyone, I am not a performance person at all, but can someone help me with pointing me in the right direction. We are running a small SYSplex, but we are getting delays on one LPAR, PROC-XCFAS *SYSTEMPROC-XCFAS 3.7 users ALL STCPROC-XCFAS 3.2 users IMS PROC-XCFAS 26.0 % delay RMFPROC-XCFAS 18.0 % delay RMFGAT PROC-XCFAS 21.0 % delay IMSCTL PROC-XCFAS 25.0 % delay TN3270 PROC-XCFAS 28.0 % delay VTAM PROC-XCFAS 19.0 % delay Also, we are ACF2 shop and our production CICS regions are getting delays: ENQ -ACFVSAM 38.0 % delay LOGONIDS ENQ -ACF2ACB 100.0 % delay LOGONIDS So any help would be great. Thanks, Jerry Edgington -- 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 ac
Re: z/OS performance question
Thanks Martin. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Martin Packer Sent: Friday, May 1, 2020 2:59 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS performance question This message was sent from an external source outside of Western & Southern's network. Do not click links or open attachments unless you recognize the sender and know the contents are safe. It's normal for different transport classes to show different request rates - and that would show up in the signalling paths they own as similar imbalances. Within a transport class would be more worrying - as that would show one path outperforming another. Actually, nowadays, CF structure paths might well show more traffic than CTCs - for the same transport class. The "structure CPU" numbers you're seeing are from R744SETM "Structure Execution Time" in SMF 74-4. There's nothing particularly bad about their numbers, and they might vary wildly by time of day. But they might cause you to look at overall CF Busy (from 74-4 rather than 70-1, though the latter would matter for SHARED CF images). Hoping this is useful. Cheers, Martin Martin Packer zChampion, Systems Investigator & Performance Troubleshooter, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2 Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA From: "Edgington, Jerry" To: IBM-MAIN@LISTSERV.UA.EDU Date: 01/05/2020 19:44 Subject: [EXTERNAL] Re: z/OS performance question Sent by:IBM Mainframe Discussion List Thanks Allen, that is good place to start. The CPU% for the ISGLOCK, IXCSTR1 and IXCSTR2 are 58%, 74% and 21%, which seem very high to me. But, the IXCSTR3 and IXCSTR4 are very low. It would seem I might have an imbalance with the XCF messages and size. Async rate for IXCSTR1 is 120 I am wondering if I need to adjust my CLASSDEF CLASSLEN size for each of the structures. We are running ICFs on GP, with one virtual connection to each ICFA/B. Not ideal, but all I could do at the moment. /* TRANSPORT CLASSES. */ CLASSDEF CLASS(SML) CLASSLEN(956) GROUP(UNDESIG) CLASSDEF CLASS(MED) CLASSLEN(8000) CLASSDEF CLASS(DEFAULT) CLASSLEN(16316) CLASSDEF CLASS(BIG) CLASSLEN(32000) /* XCF STRUCTURES */ PATHOUT STRNAME(IXCSTR1) CLASS(SML) PATHOUT STRNAME(IXCSTR2) CLASS(MED) PATHOUT STRNAME(IXCSTR3) CLASS(BIG) PATHOUT STRNAME(IXCSTR4) CLASS(DEFAULT) /* */ PATHIN STRNAME(IXCSTR1,IXCSTR2,IXCSTR3,IXCSTR4) Also, we have: FUNCTIONS ENABLE(DUPLEXCF16, SYSSTATDETECT, CRITICALPAGING) Thanks Jerry -Original Message- From: IBM Mainframe Discussion List On Behalf Of Allan Staller Sent: Friday, May 1, 2020 2:32 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS performance question This message was sent from an external source outside of Western & Southern's network. Do not click links or open attachments unless you recognize the sender and know the contents are safe. The only tuning I a aware of for XCF is to provide appropriate transport classes for the messages being passed. If inappropriate, this will usually show up as CPU concumption in the XCFAS address space. Look at the CPU consumed, not the delay. It is possible that this is contributing to the CICS delays. GRS will use XCF if available. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Edgington, Jerry Sent: Friday, May 1, 2020 12:30 PM 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.] To anyone, I am not a performance person at all, but can someone help me with pointing me in the right direction. We are running a small SYSplex, but we are getting delays on one LPAR, PROC-XCFAS *SYSTEMPROC-XCFAS 3.7 users ALL STCPROC-XCFAS 3.2 users IMS PROC-XCFAS 26.0 % delay RMFPROC-XCFAS 18.0 % delay RMFGAT PROC-XCFAS 21.0 % delay IMSCTL PROC-XCFAS 25.0 % delay TN3270 PROC-XCFAS 28.0 % delay VTAM PROC-XCFAS 19.0 % delay Also, we are ACF2 shop and our production CICS regions are getting delays: ENQ -ACFVSAM 38.0 % delay LOGONIDS ENQ -ACF2ACB 100.0 % delay LOGONIDS So any he
Re: z/OS performance question
It's normal for different transport classes to show different request rates - and that would show up in the signalling paths they own as similar imbalances. Within a transport class would be more worrying - as that would show one path outperforming another. Actually, nowadays, CF structure paths might well show more traffic than CTCs - for the same transport class. The "structure CPU" numbers you're seeing are from R744SETM "Structure Execution Time" in SMF 74-4. There's nothing particularly bad about their numbers, and they might vary wildly by time of day. But they might cause you to look at overall CF Busy (from 74-4 rather than 70-1, though the latter would matter for SHARED CF images). Hoping this is useful. Cheers, Martin Martin Packer zChampion, Systems Investigator & Performance Troubleshooter, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2 Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA From: "Edgington, Jerry" To: IBM-MAIN@LISTSERV.UA.EDU Date: 01/05/2020 19:44 Subject: [EXTERNAL] Re: z/OS performance question Sent by:IBM Mainframe Discussion List Thanks Allen, that is good place to start. The CPU% for the ISGLOCK, IXCSTR1 and IXCSTR2 are 58%, 74% and 21%, which seem very high to me. But, the IXCSTR3 and IXCSTR4 are very low. It would seem I might have an imbalance with the XCF messages and size. Async rate for IXCSTR1 is 120 I am wondering if I need to adjust my CLASSDEF CLASSLEN size for each of the structures. We are running ICFs on GP, with one virtual connection to each ICFA/B. Not ideal, but all I could do at the moment. /* TRANSPORT CLASSES. */ CLASSDEF CLASS(SML) CLASSLEN(956) GROUP(UNDESIG) CLASSDEF CLASS(MED) CLASSLEN(8000) CLASSDEF CLASS(DEFAULT) CLASSLEN(16316) CLASSDEF CLASS(BIG) CLASSLEN(32000) /* XCF STRUCTURES */ PATHOUT STRNAME(IXCSTR1) CLASS(SML) PATHOUT STRNAME(IXCSTR2) CLASS(MED) PATHOUT STRNAME(IXCSTR3) CLASS(BIG) PATHOUT STRNAME(IXCSTR4) CLASS(DEFAULT) /* */ PATHIN STRNAME(IXCSTR1,IXCSTR2,IXCSTR3,IXCSTR4) Also, we have: FUNCTIONS ENABLE(DUPLEXCF16, SYSSTATDETECT, CRITICALPAGING) Thanks Jerry -Original Message- From: IBM Mainframe Discussion List On Behalf Of Allan Staller Sent: Friday, May 1, 2020 2:32 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS performance question This message was sent from an external source outside of Western & Southern's network. Do not click links or open attachments unless you recognize the sender and know the contents are safe. The only tuning I a aware of for XCF is to provide appropriate transport classes for the messages being passed. If inappropriate, this will usually show up as CPU concumption in the XCFAS address space. Look at the CPU consumed, not the delay. It is possible that this is contributing to the CICS delays. GRS will use XCF if available. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Edgington, Jerry Sent: Friday, May 1, 2020 12:30 PM 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.] To anyone, I am not a performance person at all, but can someone help me with pointing me in the right direction. We are running a small SYSplex, but we are getting delays on one LPAR, PROC-XCFAS *SYSTEMPROC-XCFAS 3.7 users ALL STCPROC-XCFAS 3.2 users IMS PROC-XCFAS 26.0 % delay RMFPROC-XCFAS 18.0 % delay RMFGAT PROC-XCFAS 21.0 % delay IMSCTL PROC-XCFAS 25.0 % delay TN3270 PROC-XCFAS 28.0 % delay VTAM PROC-XCFAS 19.0 % delay Also, we are ACF2 shop and our production CICS regions are getting delays: ENQ -ACFVSAM 38.0 % delay LOGONIDS ENQ -ACF2ACB 100.0 % delay LOGONIDS So any help would be great. Thanks, Jerry Edgington -- 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
Re: z/OS performance question
Thanks Allen, that is good place to start. The CPU% for the ISGLOCK, IXCSTR1 and IXCSTR2 are 58%, 74% and 21%, which seem very high to me. But, the IXCSTR3 and IXCSTR4 are very low. It would seem I might have an imbalance with the XCF messages and size. Async rate for IXCSTR1 is 120 I am wondering if I need to adjust my CLASSDEF CLASSLEN size for each of the structures. We are running ICFs on GP, with one virtual connection to each ICFA/B. Not ideal, but all I could do at the moment. /* TRANSPORT CLASSES. */ CLASSDEF CLASS(SML) CLASSLEN(956) GROUP(UNDESIG) CLASSDEF CLASS(MED) CLASSLEN(8000) CLASSDEF CLASS(DEFAULT) CLASSLEN(16316) CLASSDEF CLASS(BIG) CLASSLEN(32000) /* XCF STRUCTURES */ PATHOUT STRNAME(IXCSTR1) CLASS(SML) PATHOUT STRNAME(IXCSTR2) CLASS(MED) PATHOUT STRNAME(IXCSTR3) CLASS(BIG) PATHOUT STRNAME(IXCSTR4) CLASS(DEFAULT) /* */ PATHIN STRNAME(IXCSTR1,IXCSTR2,IXCSTR3,IXCSTR4) Also, we have: FUNCTIONS ENABLE(DUPLEXCF16, SYSSTATDETECT, CRITICALPAGING) Thanks Jerry -Original Message- From: IBM Mainframe Discussion List On Behalf Of Allan Staller Sent: Friday, May 1, 2020 2:32 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS performance question This message was sent from an external source outside of Western & Southern's network. Do not click links or open attachments unless you recognize the sender and know the contents are safe. The only tuning I a aware of for XCF is to provide appropriate transport classes for the messages being passed. If inappropriate, this will usually show up as CPU concumption in the XCFAS address space. Look at the CPU consumed, not the delay. It is possible that this is contributing to the CICS delays. GRS will use XCF if available. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Edgington, Jerry Sent: Friday, May 1, 2020 12:30 PM 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.] To anyone, I am not a performance person at all, but can someone help me with pointing me in the right direction. We are running a small SYSplex, but we are getting delays on one LPAR, PROC-XCFAS *SYSTEMPROC-XCFAS 3.7 users ALL STCPROC-XCFAS 3.2 users IMS PROC-XCFAS 26.0 % delay RMFPROC-XCFAS 18.0 % delay RMFGAT PROC-XCFAS 21.0 % delay IMSCTL PROC-XCFAS 25.0 % delay TN3270 PROC-XCFAS 28.0 % delay VTAM PROC-XCFAS 19.0 % delay Also, we are ACF2 shop and our production CICS regions are getting delays: ENQ -ACFVSAM 38.0 % delay LOGONIDS ENQ -ACF2ACB 100.0 % delay LOGONIDS So any help would be great. Thanks, Jerry Edgington -- 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,
Re: z/OS performance question
The only tuning I a aware of for XCF is to provide appropriate transport classes for the messages being passed. If inappropriate, this will usually show up as CPU concumption in the XCFAS address space. Look at the CPU consumed, not the delay. It is possible that this is contributing to the CICS delays. GRS will use XCF if available. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Edgington, Jerry Sent: Friday, May 1, 2020 12:30 PM 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.] To anyone, I am not a performance person at all, but can someone help me with pointing me in the right direction. We are running a small SYSplex, but we are getting delays on one LPAR, PROC-XCFAS *SYSTEMPROC-XCFAS 3.7 users ALL STCPROC-XCFAS 3.2 users IMS PROC-XCFAS 26.0 % delay RMFPROC-XCFAS 18.0 % delay RMFGAT PROC-XCFAS 21.0 % delay IMSCTL PROC-XCFAS 25.0 % delay TN3270 PROC-XCFAS 28.0 % delay VTAM PROC-XCFAS 19.0 % delay Also, we are ACF2 shop and our production CICS regions are getting delays: ENQ -ACFVSAM 38.0 % delay LOGONIDS ENQ -ACF2ACB 100.0 % delay LOGONIDS So any help would be great. Thanks, Jerry Edgington -- 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
Re: z/OS performance question
Delays don’t really count for anything unless we know that these jobs are missing their objectives and by how much. Delays always occur. If the jobs are meeting their objectives then there is no performance problem (as far as the system is concerned). The problem, then, is that the WLM definitions are incorrect Get Outlook for iOS On Fri, May 1, 2020 at 10:29 AM -0700, "Edgington, Jerry" wrote: To anyone, I am not a performance person at all, but can someone help me with pointing me in the right direction. We are running a small SYSplex, but we are getting delays on one LPAR, PROC-XCFAS *SYSTEMPROC-XCFAS 3.7 users ALL STCPROC-XCFAS 3.2 users IMS PROC-XCFAS 26.0 % delay RMFPROC-XCFAS 18.0 % delay RMFGAT PROC-XCFAS 21.0 % delay IMSCTL PROC-XCFAS 25.0 % delay TN3270 PROC-XCFAS 28.0 % delay VTAM PROC-XCFAS 19.0 % delay Also, we are ACF2 shop and our production CICS regions are getting delays: ENQ -ACFVSAM 38.0 % delay LOGONIDS ENQ -ACF2ACB 100.0 % delay LOGONIDS So any help would be great. Thanks, Jerry Edgington -- 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
z/OS performance question
To anyone, I am not a performance person at all, but can someone help me with pointing me in the right direction. We are running a small SYSplex, but we are getting delays on one LPAR, PROC-XCFAS *SYSTEMPROC-XCFAS 3.7 users ALL STCPROC-XCFAS 3.2 users IMS PROC-XCFAS 26.0 % delay RMFPROC-XCFAS 18.0 % delay RMFGAT PROC-XCFAS 21.0 % delay IMSCTL PROC-XCFAS 25.0 % delay TN3270 PROC-XCFAS 28.0 % delay VTAM PROC-XCFAS 19.0 % delay Also, we are ACF2 shop and our production CICS regions are getting delays: ENQ -ACFVSAM 38.0 % delay LOGONIDS ENQ -ACF2ACB 100.0 % delay LOGONIDS So any help would be great. Thanks, Jerry Edgington -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
