Also keep in mind that a large proportion of IZUSVR1 CPU consumption is ZIIP eligible. I prefer to send ZIIP heavy workloads to a dedicated service class(mixing workloads might cause a ZIIP eligible workload to get denied ZIIP because the service class it is associated with is meeting its goals because of othernon-ZIIP workloads). On a busy development LPAR I use a service class with importance 5 and execution velocity of 30 and it performs well. Also keep in mind the HONORPRIORITY setting for the service class which can cause/prevent spill over of ZIIP eligible work to general usage processors.
On Fri, 12 May 2023 at 11:57, Ed Jaffe <edja...@phoenixsoftware.com> wrote: > On 5/11/2023 1:08 PM, Colin Paice wrote: > > We are setting up z/OSMF for the 1st time (can't really avoid it any > > longer). I've noticed that the IZUANG1 task has a default WLM SC of > SYSSTC > > (which is probably OK), but the IZUSVR1 task has a default of > Discretionary > > - which is probably NOT OK. Do you have a recommendation for a functional > > SC that won't eat the LPAR alive? > > We have no default Service Class for STC and no rules for IZU* address > spaces and yet our IZUSVR1 address space runs in SYSSTC under z/OS V2R5. > > > -- > Phoenix Software International > Edward E. Jaffe > 831 Parkview Drive North > El Segundo, CA 90245 > https://www.phoenixsoftware.com/ > > > > -------------------------------------------------------------------------------- > This e-mail message, including any attachments, appended messages and the > information contained therein, is for the sole use of the intended > recipient(s). If you are not an intended recipient or have otherwise > received this email message in error, any use, dissemination, distribution, > review, storage or copying of this e-mail message and the information > contained therein is strictly prohibited. If you are not an intended > recipient, please contact the sender by reply e-mail and destroy all copies > of this email message and do not otherwise utilize or retain this email > message or any or all of the information contained therein. Although this > email message and any attachments or appended messages are believed to be > free of any virus or other defect that might affect any computer system > into > which it is received and opened, it is the responsibility of the recipient > to ensure that it is virus free and no responsibility is accepted by the > sender for any loss or damage arising in any way from its opening or use. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Mike Shorkend m...@shorkend.com Tel: +972524208743 <https://www.linkedin.com/in/MikeShorkend/> <https://twitter.com/mikeShorkend> ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
