Re: WLM and TCPIP
In a message dated 2/2/2010 6:32:59 A.M. Central Standard Time, giova...@iis.com.br writes: Also Cheryl Watson's has a tunning letter from 2009 No 1 that has valious information about IEAOPT and WLM for system Z9 and Z10 and z/OS 1.9 to higger. >> She also has a product Goal Tender at _www.watsonwalker.com_ (http://www.watsonwalker.com) that will compare WLM goals vs SMF data and see where the differences lie. Don't know how it compares to IBM tools in results. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: WLM and TCPIP
Well Normally I think that WLM has a good understand and when we try to change we normally cause trouble to the system, I believe the WLM algorithm it is good enougth to work better. In some cases yes we need to do some help, but again try to do the less possible. In my understand normally VTAM and TCPIP need to have high priority like JES2, on the system that normally I can work I always use this tasks SYSSTC. IBM has some free tools that help with WLM and others parms, didn't forget that IEAOPT it is important in current days and help WLM. Wrong parms in IEAOPT you can have bad performance. WLM has a home page but here is the page for free tools http://www-03.ibm.com/servers/eserver/zseries/zos/wlm/tools/ Also Cheryl Watson's has a tunning letter from 2009 No 1 that has valious information about IEAOPT and WLM for system Z9 and Z10 and z/OS 1.9 to higger. Giovanni System Programmer -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Barbara Nitz Sent: Tuesday, February 02, 2010 2:35 AM To: IBM-MAIN@bama.ua.edu Subject: Re: WLM and TCPIP >I don't have any subsystem type TCP defined in WLM, do I really need >that? Don't think so, given that you don't have anything in SYSOTHER. >A fair amount of work?? Under subsystem type just do "create" and put >in TCP. My guess is that Allan meant a fair amount of work in *TCPIP*. >It's only used for IPSEC IIRC, so it shouldn't really matter if it is >defined or not unless the OP is using IPSEC (which I think Barbara is). Thanks Mark. Now *I* know what these TCP enclaves are for (subsystem TCP) that nobody here knew why we have them. But we do. And you're quite generous to subsys=TCP. Mine run discretionary I have defined just about any subsystem that I could and put it into discretionary, to avoid anything going to SYSOTHER. Chances are that if someone turns on something, I will not be notified to do classifications, which means this will only surface when the first person complains about bad performance. >30% of what? What is 100%? Velocity for an exvel goal. And I even found the rule in the Planning WLM book: "Certain types of work, when overachieving their goals, potentially will have their resources "capped" in order to give discretionary work a better chance to run. Specifically, work that is not part of a resource group and has one of the following two types of goals will be eligible for this resource donation: -A velocity goal of 30 or less -A response time goal of over one minute" Which does not apply to sysstc needing cpu. But it might explain why something of higher priority can run slower than discretionary. >Only batch workload is DISCRETIONARY. During the day the online >workloads >(IMS and TSO) have priority, and in the night we have enough resources so >DISCRETIONARY doesn't hurt. Do you mean the "CPU critical" flag for >guaranteed cpu? No, but since I can't remember the name of that feature, obviously I cannot search for it. It was introduced about 2 years ago via ptf. Do you run subsys=IMS? (Idle curiosity on my part, since we can't.) Your CPU capping hits when? During the day, I presume, when there isn't too much batch running? Which would mean that your discretionary pool to 'donate' isn't all that big, so higher priority work gets starved. My default service class for just about anything is discretionary, and only those that screamed at one point got an explicit mention in the policy. Here the discretionary pool is real big, but we also run a lot of batch during the day, at least in the AD systems that are hit hard when cp resources are at a premium. >> 4. Do you use the SPM rules? >Not yet. Do you see any advantage defining them? I have been using them since we migrated to WLM Goal mode. And yes, I find it really interesting what ends up in SYSSTC (and SYSTEM). The SYSTEM rule is my second in subsys STC, and I might need to change that now that we don't have report classes anymore (and make it first), and SYSSTC is my last rule in subsys STC. Just about anyone who makes itself PRIV or SYST in SCHEDxx ends up there (the monitors of any ilk at the forefront). And given that it is considered more important to get the work done than to (cpu intensively) monitor why it doesn't get done when there is not enough cpu to go around, this really helped me to reclassify STCs lower than they would like to be (take them out of sysstc). I run the monitors at the priority of the adress space they're supposed to monitor (*if* I was told to classify at all. If not -> discretionary :-)) The importance of these SPM rules may not be as high as it once were. I think that IBM/WLM has tired of customers not using them and now doesn't allow (re-)classification of a
Antwort: Re: Antwort: Re: WLM and TCPIP
IBM Mainframe Discussion List schrieb am 02.02.2010 11:01:03: > Actually, at the time of capping (and tcpip NOT running), do you have service > classes with a PI of less than 3? Less than 1? There are some SCs with a PI < 3. Very rare are PIs < 1, and then just for a minute. > Did this come up because of complaints of slow tcpip response? We have 2 java applications running on PCs which access IMS and DB2. As soon as capping starts the complaints about resp times starts as well, even the IMS resp times are good and very few batch is running. We then found out that PING times to mainframe were much longer than outside capping. Everything that handle these applications on mainframe we can imagine runs with IMP1 and exvel of 30 (the highest definition here). Since this problem is escalating internally I have opened a PMR at IBM. Regards, Werner -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Antwort: Re: WLM and TCPIP
>The highest exvel I've used so far is 30 for the online workload (IMS, >DB2). If I want limit donations from that online workload so I should >define a higher exvel than 30? yes. That's how my odd exvel31 came about. >I don't mind if higher prio work is assigned less resources under capping, >but not SYSSTC and SYSTEM. A delay of 75 for TCPIP is not acceptable. well, it might help if you bump up the exvel30 to exvel31. That *should* prevent discretionary from running. >I think when a PING is a response from TCPIP then it includes the time in >mainframe. I'll take your word for that. >> Who is using the processor when TCPIP has delays? >Mainly the batch jobs (DISCRETIONARY). I think the 'function' I meant is blocked workload support (oa17735, oa22443 to change the default). For 1.9 and up it is enabled by default, which would also explain a lower priority address space running when sysstc is not. That might run counter to an exvel goal of 31. Actually, at the time of capping (and tcpip NOT running), do you have service classes with a PI of less than 3? Less than 1? Did this come up because of complaints of slow tcpip response? Regards, Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Antwort: Re: WLM and TCPIP
IBM Mainframe Discussion List schrieb am 02.02.2010 05:34:46: > >30% of what? What is 100%? > Velocity for an exvel goal. And I even found the rule in the > Planning WLM book: > "Certain types of work, when overachieving their goals, potentially will have > their resources "capped" in order to give discretionary work a better > chance to run. Specifically, work that is not part of a resource > group and has > one of the following two types of goals will be eligible for this > resource donation: > -A velocity goal of 30 or less > -A response time goal of over one minute" > > Which does not apply to sysstc needing cpu. But it might explain why > something of higher priority can run slower than discretionary. The highest exvel I've used so far is 30 for the online workload (IMS, DB2). If I want limit donations from that online workload so I should define a higher exvel than 30? > Do you run subsys=IMS? (Idle curiosity on my part, since we can't.) Yes, we run subsys=ims with response time goals. > Your CPU capping hits when? During the day, I presume, when there isn't too > much batch running? Which would mean that your discretionary pool > to 'donate' isn't all that big, so higher priority work gets starved. Capping starts usually at late morning (11:00), we come out of the night with a low 4h-avg and batch pushes it up. It's not a question of how many jobs are running. Even one or two can use lots of CPU. I don't mind if higher prio work is assigned less resources under capping, but not SYSSTC and SYSTEM. A delay of 75 for TCPIP is not acceptable. > >We did pings and tracerte from our PC to the mainframe (including a WAN of > >1000km) and found out that only the segment from Mainframe to the first > >router has bad response times. > Does that include the time it resided *in* the mainframe? Or just when it left the mainframe? I think when a PING is a response from TCPIP then it includes the time in mainframe. > >Additionally we saw those dramatic > >increases of resp time always when capping was turned on. And RMF3 shows > >delays up to 70% for TCPIP for processor even under SYSSTC. > Who is using the processor when TCPIP has delays? Mainly the batch jobs (DISCRETIONARY). Werner Kuehnel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Antwort: Re: WLM and TCPIP
Dave, I had a similar problem with appl environments which were not defined in WLM. Since then I'm sensitive to this set of problems. No, I'm not sure it's TCPIP alone. What I see is that PING times go up when capping starts and RMF3 shows big (processor)delays for TCPIP. Werner > Are you positive it's not a spawned task that's causing the slowness ??? > Something that's being assigned service lower than SYSSTC ??? > > This sounds a lot like the FTP slowness we were experiencing. That turned out > to be a stupid oversight of not having a workload type for OMVS. TCP/IP and > the FTP daemon were running in SYSSTC, but none of the spawned tasks > were. Everything that should have been assigned a service class based on the > OMVS type ended up being assigned the default service class for the > interactive workload. Unless it runs very fast, it drops into secondand third > period service fairly quickly. I would expect a ping to reply very > quickly, but if > your WLM defaults are very low service, it may not have a chance. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: WLM and TCPIP
>I don't have any subsystem type TCP defined in WLM, do I really need >that? Don't think so, given that you don't have anything in SYSOTHER. >A fair amount of work?? Under subsystem type just do "create" and >put in TCP. My guess is that Allan meant a fair amount of work in *TCPIP*. >It's only used for IPSEC IIRC, so it shouldn't really matter if it is >defined or not unless the OP is using IPSEC (which I think Barbara >is). Thanks Mark. Now *I* know what these TCP enclaves are for (subsystem TCP) that nobody here knew why we have them. But we do. And you're quite generous to subsys=TCP. Mine run discretionary I have defined just about any subsystem that I could and put it into discretionary, to avoid anything going to SYSOTHER. Chances are that if someone turns on something, I will not be notified to do classifications, which means this will only surface when the first person complains about bad performance. >30% of what? What is 100%? Velocity for an exvel goal. And I even found the rule in the Planning WLM book: "Certain types of work, when overachieving their goals, potentially will have their resources "capped" in order to give discretionary work a better chance to run. Specifically, work that is not part of a resource group and has one of the following two types of goals will be eligible for this resource donation: -A velocity goal of 30 or less -A response time goal of over one minute" Which does not apply to sysstc needing cpu. But it might explain why something of higher priority can run slower than discretionary. >Only batch workload is DISCRETIONARY. During the day the online workloads >(IMS and TSO) have priority, and in the night we have enough resources so >DISCRETIONARY doesn't hurt. Do you mean the "CPU critical" flag for >guaranteed cpu? No, but since I can't remember the name of that feature, obviously I cannot search for it. It was introduced about 2 years ago via ptf. Do you run subsys=IMS? (Idle curiosity on my part, since we can't.) Your CPU capping hits when? During the day, I presume, when there isn't too much batch running? Which would mean that your discretionary pool to 'donate' isn't all that big, so higher priority work gets starved. My default service class for just about anything is discretionary, and only those that screamed at one point got an explicit mention in the policy. Here the discretionary pool is real big, but we also run a lot of batch during the day, at least in the AD systems that are hit hard when cp resources are at a premium. >> 4. Do you use the SPM rules? >Not yet. Do you see any advantage defining them? I have been using them since we migrated to WLM Goal mode. And yes, I find it really interesting what ends up in SYSSTC (and SYSTEM). The SYSTEM rule is my second in subsys STC, and I might need to change that now that we don't have report classes anymore (and make it first), and SYSSTC is my last rule in subsys STC. Just about anyone who makes itself PRIV or SYST in SCHEDxx ends up there (the monitors of any ilk at the forefront). And given that it is considered more important to get the work done than to (cpu intensively) monitor why it doesn't get done when there is not enough cpu to go around, this really helped me to reclassify STCs lower than they would like to be (take them out of sysstc). I run the monitors at the priority of the adress space they're supposed to monitor (*if* I was told to classify at all. If not -> discretionary :-)) The importance of these SPM rules may not be as high as it once were. I think that IBM/WLM has tired of customers not using them and now doesn't allow (re-)classification of a few of them anymore. >We did pings and tracerte from our PC to the mainframe (including a WAN of >1000km) and found out that only the segment from Mainframe to the first >router has bad response times. Does that include the time it resided *in* the mainframe? Or just when it left the mainframe? >Additionally we saw those dramatic >increases of resp time always when capping was turned on. And RMF3 shows >delays up to 70% for TCPIP for processor even under SYSSTC. Who is using the processor when TCPIP has delays? Regards, Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Antwort: Re: WLM and TCPIP
On Mon, 1 Feb 2010 07:47:34 -0600, Staller, Allan wrote: > >I don't have any subsystem type TCP defined in WLM, do I really need >that? > > >There is no such thing by default. It could be created with a fair >amount of work. > A fair amount of work?? Under subsystem type just do "create" and put in TCP. Then add a default service class and something specific if you want or need to. It's only used for IPSEC IIRC, so it shouldn't really matter if it is defined or not unless the OP is using IPSEC (which I think Barbara is). Here is what it looks like on my systems: Subsystem Type . : TCP Fold qualifier names? Y (Y or N) Description . . . TCP/IP Classification Action codes: A=After C=CopyM=Move I=Insert rule B=BeforeD=Delete row R=Repeat IS=Insert Sub-rule More ===> Qualifier ---Class ActionType Name StartService Report DEFAULTS: STCHI NETWORK 1 TN TCPENC01 ___ STCHI NETWORK Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Antwort: Re: WLM and TCPIP
I don't have any subsystem type TCP defined in WLM, do I really need that? There is no such thing by default. It could be created with a fair amount of work. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Antwort: Re: WLM and TCPIP
> 1. Check all things TCP for where they run. > There is also a subsystem type TCP, do you have this defined? Or is there > anything in service class SYSOTHER? All TCP related STCs are running with SYSSTC, no address spaces in SYSOTHER. I don't have any subsystem type TCP defined in WLM, do I really need that? > 2. For us, on the systems with very few MSUs, it is virtually > pointless to define > different exvels with the same importance level. Hence I have > restricted us to > use exactly 5 service classes with exvel goals. That's similar to our policy, one exvel within one importance. > 3. How big is your discretionary pool? Are you using this > 'guaranteed cpu' (this > is the wrong name) feature that will give even discretionary > workload a chance to run? Only batch workload is DISCRETIONARY. During the day the online workloads (IMS and TSO) have priority, and in the night we have enough resources so DISCRETIONARY doesn't hurt. Do you mean the "CPU critical" flag for guaranteed cpu? > And to add even more unclear definitions, I remember a rule that > says 'don't define an exvel goal of less than 30% - bad things will > happen'. 30% of what? What is 100%? > 4. Do you use the SPM rules? Not yet. Do you see any advantage defining them? > 5. How do you issue your ping command? TSO? As an OMVS user? Batch? I > may have overlooked that, but why do you think it is *TCPIP* that is slow > instead of however the command gets to TCPIP (and the result back)? We did pings and tracerte from our PC to the mainframe (including a WAN of 1000km) and found out that only the segment from Mainframe to the first router has bad response times. Additionally we saw those dramatic increases of resp time always when capping was turned on. And RMF3 shows delays up to 70% for TCPIP for processor even under SYSSTC. Thanks, Werner Kuehnel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: WLM and TCPIP
>We running on z10 with 16 processors (1264 MSUs), however our LPAR just >has 2 logical processors with 40 MSUs. > Tried already to shift TCPIP into SYSTEM, but is not allowed. WLM can not > starve STCs defined in SYSSTC. Why does WLM not cut the processor > for the batch jobs which are defined DISCRETIONARY? A few things to look at, but I also think you're out of luck once capping sets in: 1. Check all things TCP for where they run. This is from a machine that also has (sometimes) two cps, but *a lot* less MSUs when in a pinch: TCPRESO SCI1 TCPIPSYSSTC TCPSNMP SCI1 TCPFTP1 SCI4 TCPTNSCI1 TCPGATEP SYSSTC There is also a subsystem type TCP, do you have this defined? Or is there anything in service class SYSOTHER? 2. For us, on the systems with very few MSUs, it is virtually pointless to define different exvels with the same importance level. Hence I have restricted us to use exactly 5 service classes with exvel goals (more SC periods for response time goals), and they basically only differ in the importance level. SCI6 is discretionary. And yes, STC and batch get mixed in the same SC. Ever since I have changed the policy to use these, we feel that an IPL (even when the box is 100% busy) works much smoother and faster than before. This is from the sysprog sandplex. For Production I wasn't allowed yet to change, so I cannot comment on production. 3. How big is your discretionary pool? Are you using this 'guaranteed cpu' (this is the wrong name) feature that will give even discretionary workload a chance to run? And to add even more unclear definitions, I remember a rule that says 'don't define an exvel goal of less than 30% - bad things will happen'. I don't even remember what those bad things were, though, but I still follow that rule. 4. Do you use the SPM rules? 5. How do you issue your ping command? TSO? As an OMVS user? Batch? I may have overlooked that, but why do you think it is *TCPIP* that is slow instead of however the command gets to TCPIP (and the result back)? Now, please someone refresh my memory what those bad things are and how that WLM feature is really called! :-) Regards, Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Antwort: Re: Antwort: Re: Antwort: Re: WLM and TCPIP
We running on z10 with 16 processors (1264 MSUs), however our LPAR just has 2 logical processors with 40 MSUs. Werner Kuehnel IBM Mainframe Discussion List schrieb am 29.01.2010 17:02:32: > Werner, > > I'm curious, how many CPU's? > > > --- On Fri, 1/29/10, Werner Kuehnel wrote: > > > From: Werner Kuehnel > Subject: Antwort: Re: Antwort: Re: WLM and TCPIP > To: IBM-MAIN@bama.ua.edu > Date: Friday, January 29, 2010, 2:30 PM > > > The "normal" delay is under 10%. I can't think of another address space > than TCPIP > to handle the PING. Probably OMPROUTE, but it's also defined as SYSSTC and > is > delayed for a much higher percentage than at normal times. > > Werner Kuehnel > > > IBM Mainframe Discussion List schrieb am 29.01.2010 > 15:11:24: > > > Ignorant questions: > > Does TCPIP handle the Ping itself, so no other adress space is involved? > > What is the delay % under normal (good) response situations? > > > > Kees. > > > > "Werner Kuehnel" wrote in message > > news: > er.de>... > > > Tried already to shift TCPIP into SYSTEM, but is not allowed. WLM can > > not > > > starve STCs defined in SYSSTC. Why does WLM not cut the processor for > > the > > > batch jobs which are defined DISCRETIONARY? > > > > > > Werner Kuehnel > > > > > > > > > IBM Mainframe Discussion List schrieb am > > 29.01.2010 > > > 14:49:44: > > > > > > > Given the situation I would say, probably, NO. You *might* be able > > to > > > > move TCPIP to SYSTEM but ISTR some changes made a few releases back > > to > > > > force certain system critical tasks into IBM assigned SCLASSes. > > > > > > > > The problem is not the TCPIP is not high enough on the food chain, > > but > > > > that the food chain has been shortened when the soft cap kicks in. > > This > > > > is the most likely causes of CPU delay. > > > > > > > > Possible Performance improvements for TCPIP > > > > Segmentation Offload. Not sure of the current status. A long history > > of > > > > trys, retrys, and try agains. Check the archives. > > > > There are a couple of TCPIP performance Inoforamation APARS the also > > > > might help II11710, II11711, II11712. None of these "address" CPU > > > > directly, but the net effect will be to reduce the CPU overhead per > > byte > > > > when implemented. > > > > > > > > HTH, > > > > > > > > > > > > Our box is running at 90-100% under soft capping. > > > > TCPIP is defined with service class SYSSTC. > > > > When capping starts the PING response times explode from approx. > > 15ms to > > > > > > > > 400 - 1000ms. Looking with RMF3 delay monitor at TCPIP, it shows a > > delay > > > > > > > > up to 70% because of processor. > > > > SYSSTC is the highest service class I can assign, it runs with > > > > dispatching > > > > prio of FE. Nevertheless TCPIP is delayed at such a high degree. > > > > Is there anything I can do to improve the performance of TCPIP? > > > > > > > > > > > > > > -- > > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN > > INFO > > > > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > > > > > -- > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > > > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > ** > > For information, services and offers, please visit our web site: > > http://www.klm.com. This e-mail and any attachment may contain > > confidential and privileged material intended for the addressee > > only. If you are not the addressee, you are notified that no part > > of the e-mail or any attachment may be disclosed, copied or > > distributed, and that any other action related to this e-mail or > > attachment is strictly prohibited, and may be unlawful. If you
Antwort: Re: WLM and TCPIP
Jim, we don't have DB2 in SYSSTC, just the IRLMs. Application Server run in an own SC with a high goal, but still lower than SYSSTC. Werner Kuehnel IBM Mainframe Discussion List schrieb am 29.01.2010 16:18:18: > On Fri, Jan 29, 2010 at 2:59 PM, Werner Kuehnel < > werner.kueh...@mannheimer.de> wrote: > > > Well, of course I can do that but they always warn to define unachievable > > SCs. > > Anyway, I'll give it a try. > > > > Werner Kuehnel > > > > > BTW we don't have any "application server STCs" that can potentially do a > lot of work such as the DB2* address spaces in SYSSTC. They run separately > at a lower priority which is why I thought it could possibly be implemented. > > Jim McAlpine > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Antwort: Re: WLM and TCPIP
Unfortunately I don't have the data available anymore from last week. For another PMR at IBM I had to change the RMF intervall from 1h to 15min and the higher amount of data shortens the available period in RMF3. It's time to adjust the dataset sizes.. But this week is expected to get again a high cpu usage with lots of capping. I always have a display sorted by CPU%, nothing catched my eye from SYSTEM SC. RMF shows almost always normal batch jobs from appl dev and production (all running DISCRETIONARY). It's hard to say if other address spaces from SYSSTC suffer like TCPIP from observation. Many STCs are IRLMs for DB2 (probably have a stake in bad response times) or monitors (which have an ISPF interface and bad behaviour is covered by bad TSO response times). I'll watch RMF3 next time. Werner Kuehnel IBM Mainframe Discussion List schrieb am 29.01.2010 15:57:36: > On Fri, 29 Jan 2010 14:40:21 +0100, Werner Kuehnel > wrote: > > >Our box is running at 90-100% under soft capping. > >TCPIP is defined with service class SYSSTC. > >When capping starts the PING response times explode from approx. 15ms to > >400 - 1000ms. Looking with RMF3 delay monitor at TCPIP, it shows a delay > >up to 70% because of processor. > >SYSSTC is the highest service class I can assign, it runs with dispatching > >prio of FE. Nevertheless TCPIP is delayed at such a high degree. > >Is there anything I can do to improve the performance of TCPIP? > > > > I don't think there is much you can do. Does RMF III show the same > delay for all of SYSSTC? What about SYSTEM? If SYSSTC is delayed > and it is because of processor, the only higher DP address spaces > are SYSTEM, If you look at all yourSYSTEM address spaces in > SDSF and sort by CPU%, does that give any clues? What does > RMF III show as the job(s) that are causing the CPU delay? > > Just out of curiosity, what do you observe with other SYSSTC service > class address spaces at the same time. For example, comparing a JES2 > command response during this time to a time when you aren't running > at or new 100%? What about a CONSOLE response to some display > commands like "D GRS,C" (CONSOLE and GRS run in SYSTEM)? > > Mark > -- > Mark Zelden > Sr. Software and Systems Architect - z/OS Team Lead > Zurich North America / Farmers Insurance Group - ZFUS G-ITO > mailto:mark.zel...@zurichna.com > z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ > Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: WLM and TCPIP
On Fri, 29 Jan 2010 08:58:11 -0600, Mark Zelden wrote: >On Fri, 29 Jan 2010 14:29:24 +, Jim McAlpine wrote: > >>On Fri, Jan 29, 2010 at 2:02 PM, Werner Kuehnel < >>werner.kueh...@mannheimer.de> wrote: >> >>> Tried already to shift TCPIP into SYSTEM, but is not allowed. WLM can not >>> starve STCs defined in SYSSTC. Are you positive it's not a spawned task that's causing the slowness ??? Something that's being assigned service lower than SYSSTC ??? This sounds a lot like the FTP slowness we were experiencing. That turned out to be a stupid oversight of not having a workload type for OMVS. TCP/IP and the FTP daemon were running in SYSSTC, but none of the spawned tasks were. Everything that should have been assigned a service class based on the OMVS type ended up being assigned the default service class for the interactive workload. Unless it runs very fast, it drops into second and third period service fairly quickly. I would expect a ping to reply very quickly, but if your WLM defaults are very low service, it may not have a chance. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Antwort: Re: Antwort: Re: WLM and TCPIP
Werner, I'm curious, how many CPU's? --- On Fri, 1/29/10, Werner Kuehnel wrote: From: Werner Kuehnel Subject: Antwort: Re: Antwort: Re: WLM and TCPIP To: IBM-MAIN@bama.ua.edu Date: Friday, January 29, 2010, 2:30 PM The "normal" delay is under 10%. I can't think of another address space than TCPIP to handle the PING. Probably OMPROUTE, but it's also defined as SYSSTC and is delayed for a much higher percentage than at normal times. Werner Kuehnel IBM Mainframe Discussion List schrieb am 29.01.2010 15:11:24: > Ignorant questions: > Does TCPIP handle the Ping itself, so no other adress space is involved? > What is the delay % under normal (good) response situations? > > Kees. > > "Werner Kuehnel" wrote in message > news: er.de>... > > Tried already to shift TCPIP into SYSTEM, but is not allowed. WLM can > not > > starve STCs defined in SYSSTC. Why does WLM not cut the processor for > the > > batch jobs which are defined DISCRETIONARY? > > > > Werner Kuehnel > > > > > > IBM Mainframe Discussion List schrieb am > 29.01.2010 > > 14:49:44: > > > > > Given the situation I would say, probably, NO. You *might* be able > to > > > move TCPIP to SYSTEM but ISTR some changes made a few releases back > to > > > force certain system critical tasks into IBM assigned SCLASSes. > > > > > > The problem is not the TCPIP is not high enough on the food chain, > but > > > that the food chain has been shortened when the soft cap kicks in. > This > > > is the most likely causes of CPU delay. > > > > > > Possible Performance improvements for TCPIP > > > Segmentation Offload. Not sure of the current status. A long history > of > > > trys, retrys, and try agains. Check the archives. > > > There are a couple of TCPIP performance Inoforamation APARS the also > > > might help II11710, II11711, II11712. None of these "address" CPU > > > directly, but the net effect will be to reduce the CPU overhead per > byte > > > when implemented. > > > > > > HTH, > > > > > > > > > Our box is running at 90-100% under soft capping. > > > TCPIP is defined with service class SYSSTC. > > > When capping starts the PING response times explode from approx. > 15ms to > > > > > > 400 - 1000ms. Looking with RMF3 delay monitor at TCPIP, it shows a > delay > > > > > > up to 70% because of processor. > > > SYSSTC is the highest service class I can assign, it runs with > > > dispatching > > > prio of FE. Nevertheless TCPIP is delayed at such a high degree. > > > Is there anything I can do to improve the performance of TCPIP? > > > > > > > > > > -- > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN > INFO > > > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > > Search the archives at http://bama.ua.edu/archives/ibm-main.html > ** > For information, services and offers, please visit our web site: > http://www.klm.com. This e-mail and any attachment may contain > confidential and privileged material intended for the addressee > only. If you are not the addressee, you are notified that no part > of the e-mail or any attachment may be disclosed, copied or > distributed, and that any other action related to this e-mail or > attachment is strictly prohibited, and may be unlawful. If you have > received this e-mail by error, please notify the sender immediately > by return e-mail, and delete this message. > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries > and/or its employees shall not be liable for the incorrect or > incomplete transmission of this e-mail or any attachments, nor > responsible for any delay in receipt. > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal > Dutch Airlines) is registered in Amstelveen, The Netherlands, with > registered number 33014286 > ** > > -- > For IBM-MAIN subscribe / sign
Re: Antwort: Re: Antwort: Re: WLM and TCPIP
That is why I said "very carefully" Turning on offload I'm a bit hesitant.. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: WLM and TCPIP
On Fri, Jan 29, 2010 at 2:59 PM, Werner Kuehnel < werner.kueh...@mannheimer.de> wrote: > Well, of course I can do that but they always warn to define unachievable > SCs. > Anyway, I'll give it a try. > > Werner Kuehnel > > BTW we don't have any "application server STCs" that can potentially do a lot of work such as the DB2* address spaces in SYSSTC. They run separately at a lower priority which is why I thought it could possibly be implemented. Jim McAlpine -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Antwort: Re: WLM and TCPIP
Well, of course I can do that but they always warn to define unachievable SCs. Anyway, I'll give it a try. Werner Kuehnel IBM Mainframe Discussion List schrieb am 29.01.2010 15:51:43: > On Fri, Jan 29, 2010 at 2:47 PM, Werner Kuehnel < > werner.kueh...@mannheimer.de> wrote: > > > Jim, while you can assign STCs to SC SYSSTC there is no definition > > in WLM and no way to set the CPU critical flag. > > > > Werner Kuehnel > > > > > Could you not set up another service class just for tcp/ip with importance 1 > and velocity 99 and cpu critical. > > As I said, I've never tried it. > > Jim McAlpine > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: WLM and TCPIP
On Fri, 29 Jan 2010 14:29:24 +, Jim McAlpine wrote: >On Fri, Jan 29, 2010 at 2:02 PM, Werner Kuehnel < >werner.kueh...@mannheimer.de> wrote: > >> Tried already to shift TCPIP into SYSTEM, but is not allowed. WLM can not >> starve STCs defined in SYSSTC. Why does WLM not cut the processor for the >> batch jobs which are defined DISCRETIONARY? >> >> Werner Kuehnel >> >> >> Never used it myself, but would the "cpu critical" attribute help in this >instance. > No. SYSSTC and SYSTEM have a fixed DP. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: WLM and TCPIP
On Fri, 29 Jan 2010 14:40:21 +0100, Werner Kuehnel wrote: >Our box is running at 90-100% under soft capping. >TCPIP is defined with service class SYSSTC. >When capping starts the PING response times explode from approx. 15ms to >400 - 1000ms. Looking with RMF3 delay monitor at TCPIP, it shows a delay >up to 70% because of processor. >SYSSTC is the highest service class I can assign, it runs with dispatching >prio of FE. Nevertheless TCPIP is delayed at such a high degree. >Is there anything I can do to improve the performance of TCPIP? > I don't think there is much you can do. Does RMF III show the same delay for all of SYSSTC? What about SYSTEM? If SYSSTC is delayed and it is because of processor, the only higher DP address spaces are SYSTEM, If you look at all yourSYSTEM address spaces in SDSF and sort by CPU%, does that give any clues? What does RMF III show as the job(s) that are causing the CPU delay? Just out of curiosity, what do you observe with other SYSSTC service class address spaces at the same time. For example, comparing a JES2 command response during this time to a time when you aren't running at or new 100%? What about a CONSOLE response to some display commands like "D GRS,C" (CONSOLE and GRS run in SYSTEM)? Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: WLM and TCPIP
On Fri, Jan 29, 2010 at 2:47 PM, Werner Kuehnel < werner.kueh...@mannheimer.de> wrote: > Jim, while you can assign STCs to SC SYSSTC there is no definition > in WLM and no way to set the CPU critical flag. > > Werner Kuehnel > > Could you not set up another service class just for tcp/ip with importance 1 and velocity 99 and cpu critical. As I said, I've never tried it. Jim McAlpine -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Antwort: Re: WLM and TCPIP
Jim, while you can assign STCs to SC SYSSTC there is no definition in WLM and no way to set the CPU critical flag. Werner Kuehnel IBM Mainframe Discussion List schrieb am 29.01.2010 15:29:24: > On Fri, Jan 29, 2010 at 2:02 PM, Werner Kuehnel < > werner.kueh...@mannheimer.de> wrote: > > > Tried already to shift TCPIP into SYSTEM, but is not allowed. WLM can not > > starve STCs defined in SYSSTC. Why does WLM not cut the processor for the > > batch jobs which are defined DISCRETIONARY? > > > > Werner Kuehnel > > > > > > Never used it myself, but would the "cpu critical" attribute help in this > instance. > > Jim McAlpine > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Antwort: Re: Antwort: Re: WLM and TCPIP
Thanks for your help, Allen, I'll check out the APARs. Turning on offload I'm a bit hesitant.. Werner Kuehnel IBM Mainframe Discussion List schrieb am 29.01.2010 15:13:33: > Check out the info apars and (very carefully!) check out segmentation > offload. You might want to bounce this off of IBM (either WLM or Comm. > Server ). > > That's about all I can recommend. Please post the results when/if there > are any. I would be interested in the responses from IBM. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Antwort: Re: Antwort: Re: WLM and TCPIP
The "normal" delay is under 10%. I can't think of another address space than TCPIP to handle the PING. Probably OMPROUTE, but it's also defined as SYSSTC and is delayed for a much higher percentage than at normal times. Werner Kuehnel IBM Mainframe Discussion List schrieb am 29.01.2010 15:11:24: > Ignorant questions: > Does TCPIP handle the Ping itself, so no other adress space is involved? > What is the delay % under normal (good) response situations? > > Kees. > > "Werner Kuehnel" wrote in message > news: er.de>... > > Tried already to shift TCPIP into SYSTEM, but is not allowed. WLM can > not > > starve STCs defined in SYSSTC. Why does WLM not cut the processor for > the > > batch jobs which are defined DISCRETIONARY? > > > > Werner Kuehnel > > > > > > IBM Mainframe Discussion List schrieb am > 29.01.2010 > > 14:49:44: > > > > > Given the situation I would say, probably, NO. You *might* be able > to > > > move TCPIP to SYSTEM but ISTR some changes made a few releases back > to > > > force certain system critical tasks into IBM assigned SCLASSes. > > > > > > The problem is not the TCPIP is not high enough on the food chain, > but > > > that the food chain has been shortened when the soft cap kicks in. > This > > > is the most likely causes of CPU delay. > > > > > > Possible Performance improvements for TCPIP > > > Segmentation Offload. Not sure of the current status. A long history > of > > > trys, retrys, and try agains. Check the archives. > > > There are a couple of TCPIP performance Inoforamation APARS the also > > > might help II11710, II11711, II11712. None of these "address" CPU > > > directly, but the net effect will be to reduce the CPU overhead per > byte > > > when implemented. > > > > > > HTH, > > > > > > > > > Our box is running at 90-100% under soft capping. > > > TCPIP is defined with service class SYSSTC. > > > When capping starts the PING response times explode from approx. > 15ms to > > > > > > 400 - 1000ms. Looking with RMF3 delay monitor at TCPIP, it shows a > delay > > > > > > up to 70% because of processor. > > > SYSSTC is the highest service class I can assign, it runs with > > > dispatching > > > prio of FE. Nevertheless TCPIP is delayed at such a high degree. > > > Is there anything I can do to improve the performance of TCPIP? > > > > > > > > > > -- > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN > INFO > > > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > > Search the archives at http://bama.ua.edu/archives/ibm-main.html > ** > For information, services and offers, please visit our web site: > http://www.klm.com. This e-mail and any attachment may contain > confidential and privileged material intended for the addressee > only. If you are not the addressee, you are notified that no part > of the e-mail or any attachment may be disclosed, copied or > distributed, and that any other action related to this e-mail or > attachment is strictly prohibited, and may be unlawful. If you have > received this e-mail by error, please notify the sender immediately > by return e-mail, and delete this message. > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries > and/or its employees shall not be liable for the incorrect or > incomplete transmission of this e-mail or any attachments, nor > responsible for any delay in receipt. > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal > Dutch Airlines) is registered in Amstelveen, The Netherlands, with > registered number 33014286 > ** > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: WLM and TCPIP
On Fri, Jan 29, 2010 at 2:02 PM, Werner Kuehnel < werner.kueh...@mannheimer.de> wrote: > Tried already to shift TCPIP into SYSTEM, but is not allowed. WLM can not > starve STCs defined in SYSSTC. Why does WLM not cut the processor for the > batch jobs which are defined DISCRETIONARY? > > Werner Kuehnel > > > Never used it myself, but would the "cpu critical" attribute help in this instance. Jim McAlpine -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Antwort: Re: WLM and TCPIP
Check out the info apars and (very carefully!) check out segmentation offload. You might want to bounce this off of IBM (either WLM or Comm. Server ). That's about all I can recommend. Please post the results when/if there are any. I would be interested in the responses from IBM. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Werner Kuehnel Sent: Friday, January 29, 2010 8:03 AM To: IBM-MAIN@bama.ua.edu Subject: Antwort: Re: WLM and TCPIP Tried already to shift TCPIP into SYSTEM, but is not allowed. WLM can not starve STCs defined in SYSSTC. Why does WLM not cut the processor for the batch jobs which are defined DISCRETIONARY? Werner Kuehnel IBM Mainframe Discussion List schrieb am 29.01.2010 14:49:44: > Given the situation I would say, probably, NO. You *might* be able to > move TCPIP to SYSTEM but ISTR some changes made a few releases back to > force certain system critical tasks into IBM assigned SCLASSes. > > The problem is not the TCPIP is not high enough on the food chain, but > that the food chain has been shortened when the soft cap kicks in. This > is the most likely causes of CPU delay. > > Possible Performance improvements for TCPIP > Segmentation Offload. Not sure of the current status. A long history of > trys, retrys, and try agains. Check the archives. > There are a couple of TCPIP performance Inoforamation APARS the also > might help II11710, II11711, II11712. None of these "address" CPU > directly, but the net effect will be to reduce the CPU overhead per byte > when implemented. > > HTH, > > > Our box is running at 90-100% under soft capping. > TCPIP is defined with service class SYSSTC. > When capping starts the PING response times explode from approx. 15ms to > > 400 - 1000ms. Looking with RMF3 delay monitor at TCPIP, it shows a delay > > up to 70% because of processor. > SYSSTC is the highest service class I can assign, it runs with > dispatching > prio of FE. Nevertheless TCPIP is delayed at such a high degree. > Is there anything I can do to improve the performance of TCPIP? > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Antwort: Re: WLM and TCPIP
Ignorant questions: Does TCPIP handle the Ping itself, so no other adress space is involved? What is the delay % under normal (good) response situations? Kees. "Werner Kuehnel" wrote in message news:... > Tried already to shift TCPIP into SYSTEM, but is not allowed. WLM can not > starve STCs defined in SYSSTC. Why does WLM not cut the processor for the > batch jobs which are defined DISCRETIONARY? > > Werner Kuehnel > > > IBM Mainframe Discussion List schrieb am 29.01.2010 > 14:49:44: > > > Given the situation I would say, probably, NO. You *might* be able to > > move TCPIP to SYSTEM but ISTR some changes made a few releases back to > > force certain system critical tasks into IBM assigned SCLASSes. > > > > The problem is not the TCPIP is not high enough on the food chain, but > > that the food chain has been shortened when the soft cap kicks in. This > > is the most likely causes of CPU delay. > > > > Possible Performance improvements for TCPIP > > Segmentation Offload. Not sure of the current status. A long history of > > trys, retrys, and try agains. Check the archives. > > There are a couple of TCPIP performance Inoforamation APARS the also > > might help II11710, II11711, II11712. None of these "address" CPU > > directly, but the net effect will be to reduce the CPU overhead per byte > > when implemented. > > > > HTH, > > > > > > Our box is running at 90-100% under soft capping. > > TCPIP is defined with service class SYSSTC. > > When capping starts the PING response times explode from approx. 15ms to > > > > 400 - 1000ms. Looking with RMF3 delay monitor at TCPIP, it shows a delay > > > > up to 70% because of processor. > > SYSSTC is the highest service class I can assign, it runs with > > dispatching > > prio of FE. Nevertheless TCPIP is delayed at such a high degree. > > Is there anything I can do to improve the performance of TCPIP? > > > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Antwort: Re: WLM and TCPIP
Tried already to shift TCPIP into SYSTEM, but is not allowed. WLM can not starve STCs defined in SYSSTC. Why does WLM not cut the processor for the batch jobs which are defined DISCRETIONARY? Werner Kuehnel IBM Mainframe Discussion List schrieb am 29.01.2010 14:49:44: > Given the situation I would say, probably, NO. You *might* be able to > move TCPIP to SYSTEM but ISTR some changes made a few releases back to > force certain system critical tasks into IBM assigned SCLASSes. > > The problem is not the TCPIP is not high enough on the food chain, but > that the food chain has been shortened when the soft cap kicks in. This > is the most likely causes of CPU delay. > > Possible Performance improvements for TCPIP > Segmentation Offload. Not sure of the current status. A long history of > trys, retrys, and try agains. Check the archives. > There are a couple of TCPIP performance Inoforamation APARS the also > might help II11710, II11711, II11712. None of these "address" CPU > directly, but the net effect will be to reduce the CPU overhead per byte > when implemented. > > HTH, > > > Our box is running at 90-100% under soft capping. > TCPIP is defined with service class SYSSTC. > When capping starts the PING response times explode from approx. 15ms to > > 400 - 1000ms. Looking with RMF3 delay monitor at TCPIP, it shows a delay > > up to 70% because of processor. > SYSSTC is the highest service class I can assign, it runs with > dispatching > prio of FE. Nevertheless TCPIP is delayed at such a high degree. > Is there anything I can do to improve the performance of TCPIP? > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: WLM and TCPIP
Given the situation I would say, probably, NO. You *might* be able to move TCPIP to SYSTEM but ISTR some changes made a few releases back to force certain system critical tasks into IBM assigned SCLASSes. The problem is not the TCPIP is not high enough on the food chain, but that the food chain has been shortened when the soft cap kicks in. This is the most likely causes of CPU delay. Possible Performance improvements for TCPIP Segmentation Offload. Not sure of the current status. A long history of trys, retrys, and try agains. Check the archives. There are a couple of TCPIP performance Inoforamation APARS the also might help II11710, II11711, II11712. None of these "address" CPU directly, but the net effect will be to reduce the CPU overhead per byte when implemented. HTH, Our box is running at 90-100% under soft capping. TCPIP is defined with service class SYSSTC. When capping starts the PING response times explode from approx. 15ms to 400 - 1000ms. Looking with RMF3 delay monitor at TCPIP, it shows a delay up to 70% because of processor. SYSSTC is the highest service class I can assign, it runs with dispatching prio of FE. Nevertheless TCPIP is delayed at such a high degree. Is there anything I can do to improve the performance of TCPIP? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
WLM and TCPIP
Our box is running at 90-100% under soft capping. TCPIP is defined with service class SYSSTC. When capping starts the PING response times explode from approx. 15ms to 400 - 1000ms. Looking with RMF3 delay monitor at TCPIP, it shows a delay up to 70% because of processor. SYSSTC is the highest service class I can assign, it runs with dispatching prio of FE. Nevertheless TCPIP is delayed at such a high degree. Is there anything I can do to improve the performance of TCPIP? Werner Kuehnel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
