Adam asked me to post something about mainframe load—“what’s the biggest source of load, what’s next, where’s broker, ADABAS, etc.” Let me start by showing a ten second snapshot I just took (2:10 pm) of CPU usage by job:
CPU BUSY 94% 10 SEC SAMPLE 4 CPUS ACTIVE JES UTCOM7 26% OF CPU BUSY E8 <-- PRIORITY JES UTPRD2 11% OF CPU BUSY EA <-- PRIORITY JES UTPRD1 5% OF CPU BUSY EA <-- PRIORITY STC UTETB1 4% OF CPU BUSY EE <-- PRIORITY JES UTQUA1 4% OF CPU BUSY DC <-- PRIORITY JES UTCOM4 4% OF CPU BUSY E8 <-- PRIORITY JES UTPRD5 4% OF CPU BUSY EA <-- PRIORITY STC UTNDVT 3% OF CPU BUSY F4 <-- PRIORITY JES UTCOM2 3% OF CPU BUSY E8 <-- PRIORITY JES UTQUA5 3% OF CPU BUSY DC <-- PRIORITY JES UTCOM8 2% OF CPU BUSY E8 <-- PRIORITY JES SGNWFL9D 2% OF CPU BUSY C0 <-- PRIORITY JES EWNWEOMO 2% OF CPU BUSY C1 <-- PRIORITY JES UTCOM1 1% OF CPU BUSY E8 <-- PRIORITY JES UTQUA4 1% OF CPU BUSY DC <-- PRIORITY JES UTPRD4 1% OF CPU BUSY EA <-- PRIORITY JES NRNW2041 1% OF CPU BUSY C8 <-- PRIORITY JES EINWAEVE 1% OF CPU BUSY C0 <-- PRIORITY
This is fairly typical of what we’ve been seeing this week. UTCOMx jobs are the COM-PLETEs; UTCOM7 is where most production Broker servers run, UTCOM2 is “Fiscal”, etc. They typically represent about a quarter to a third of the CPU being used during prime shift. UTPRDx jobs are the production Adabas databases, and they typically take up a fifth to a quarter of the CPU usage. UTQUAx are the quality assurance Adabas databases; their usage is highly variable. (Test Adabas databases are named UTTSTx; none of them was using enough CPU to show up when I took this snapshot.)
UTETBx jobs are Broker; UTETB1 is the production Broker nucleus. This is where the big difference has been during this semester’s registration: before I installed EntireX version 8 over the summer, Broker used about the same amount of CPU as COM-PLETE, but once I installed the new version, it dropped down to between a fourth and a sixth of that. If we were still at version 7 of Broker, it would have been taking up between 20 and 25% of the CPU, instead of around 5%.
I’ll also draw your attention to the priorities. (Those are hexadecimal numbers, by the way.) Broker has the highest priority, with production Adabas next and COM-PLETE next. Batch jobs are at the very bottom. The MVS dispatcher always selects the highest priority job that’s ready to use the CPU. If Broker were still using 20% or so of the CPU, the QUAL databases and the batch jobs would just be out of luck—they’d still be running, but they would never get a chance to use the CPU.
I’ll watch for any questions in the comments, or you can email me and I’ll post the answers.
I just have a quick clarification point to ask: UTCOM7 is where most production Broker servers run and UTETB1 is where the production Broker nucleus lives. Does that mean that UTETB1 is, in some sense, the Broker service itself, while UTCOM7 is where the called modules, like Natural web wrappers run?
I *think* that’s the case based on where the savings were seen upgrading to EntireX v8, but I just want to make sure my mental model is right.
What runs in COM-PLETE is all the Natural code that provides your service. This is what you’re starting when you use the TR command in *DPUSER and what you see on the TF command there. The Broker nucleus (UTETB1) keeps track of the services that have registered, and when a request comes in passes it to the appropriate server and then sends back the response. The nucleus’ job is to handle all the communication and to match up clients and servers.
I’m not sure exactly what Software AG changed to get the CPU improvements. If I had to guess, it would be that most of it comes from a more efficient algorithm for finding the server registration that matches a client request. I’ve heard that the new version was a major rewrite, so there may be a lot of little improvements that add up to this big win.
Another thing I might mention: there is a small piece of Broker that runs in the Natural session in COM-PLETE. It just handles communication with the nucleus and is so small it’s called a “stub”. We haven’t yet upgraded the stub; what’s running now is the version 7 stub. We had a meeting this morning where we talked about this (and other things) and decided to include installing the version 8 stub as part of the rollout of the next Natural version.
Thanks, Curtis. This is exactly what I was hoping for.