Thank you Ed, excellent suggestion. I too have felt the z/OSMF cpu cycles were exorbitant, but assuming you have sufficient zIIP capacity and ZZ=YES, which now appears to be the default, then high cycles might in reality be more of a perception problem if a person is looking at a generalized cpu bucket (as I was) rather than GP, zIIP, and zAAP contributions individually.
Another item, in the context of z/OSMF resource utilization as part of the ZOWE software stack is what I regarded as high EXCP counts when the system is idling. Over a 30hr period this translated to approximately 300 EXCPs/second from z/OSMF. I have heard from two sources that this may be due to a rather primitive technique used by ZOWE to check for new work requests - that of interrogating data sets for additions/changes. I would think some flavor of wait-post would be far more efficient. Has anyone else noticed this behavior or better yet, aware of a fix for it? Added Colin Paice's post to the end of this thread since it got dropped and seemed quite relevant. Thanks much, Mike -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Jaffe Sent: Saturday, July 17, 2021 7:24 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Serverpac installs January 2022 and beyond Caution! This message was sent from outside your organization. On 7/17/2021 3:46 AM, Brian Westerman wrote: > Asking a site that is able to function within their requirements and existing > SLA's to upgrade their box to more than 4x the existing size just to run > z/OSMF is just never going to be economically feasible. Even on sites with > larger machines, they may not have the extra capacity to provide z/OSMF with > what it needs to function properly. Since z/OSMF is a Java application, there is no need to upgrade the box at all in the classic sense of increasing its MSU capacity. What you do instead is purchase/enable a single zIIP engine, share it among all z/OS LPARs via the HMC, and set ZZ=YES (zAAP on zIIP) in IEASYSxx on z/OS. Voila! z/OSMF runs like a champ and your software bill does not go up one iota. In fact, it could go down slightly due to zIIP exploitation by other CPU-hungry products. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Colin Paice Sent: Saturday, July 17, 2021 8:43 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Serverpac installs January 2022 and beyond One issue is that z/OSMF is expensive in CPU. I noticed in the system trace, that there are 500 storage requests (eg getmain/freemain) for each http rest message coming in. Getting rid of these expensive requests would reduce the costs. I think all of these come from below the Java level, such as BPX* modules. For example, write an SMF record from C requires a getmain .. write SMF record - free main. Ive blogged <https://colinpaice.blog/2020/12/21/a-practical-guide-to-getting-z-osmf-working/> on getting z/OSMF working including digital certificates. Unfortunately I dont think they have designed it properly. Other products have the "keystore" (keyring), containing just the private key for the server, and the "trust store" (keyring) containing the public certificate needed to validate any certificates sent to the server. This trust store can be used by all products (Sysplex wide). z/OSMF just uses one, combined, store(keying). This means I cant just reuse my existing certificate set up, and so I have to have a dedicated keyring for each z/OSMF. This makes the setup much harder, and makes administration hard. It is not much code to fix it ( I implemented it in my Java server). I think that z/OSMF could be great for the younger generations to get up to speed. But it needs to be improved to make it low cost and easy to install and configure (as in get it into production, rather than just get it started). Colin ---------------------------------------------------------------------- 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
