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 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 ---------------------------------------------------------------------- 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
