Review of CMS (CPU Management System)
by
Shawn M. Gordon
President
S.M.Gordon & Associates
Introduction
CMS allows you granular control over the CPU Dispatcher on the HP 3000. That said, I think I should probably stop and explain a little about the dispatcher.
Perhaps you are familiar with the dispatcher on MPE, it’s that TUNE command that you hardly ever use to specify the filter and/or priority limits of the circular subqueues CS, DS, ES. The only control HP ever gave you over these was
being able to define the start and end points of each queues priority and the minimum and maximum filters, which the CPU uses to determine if a process should be decreased in priority, for each of the queues. A few years ago they gave
us some enhancements to the TUNE command, namely OSCILLATE, to give some finer control.
I know it took me some time to understand how the TUNE command worked and even more time to determine what where the best values for my system, because you can REALLY foul up your response time by setting these badly. The beauty of CMS
is that it allows you to allocate these queue resources exactly how you want to, down to a process or user level, thus giving you the ability to really fine tune your response time.
CMS was devloped by the same man who originally developed KLA/EXPRESS, which was purchased by Unison software in 1991. I used CMS on my HP 3000 series 925 running MPE/iX 4.0
Features
I am going to start this review with a slightly more technical discussion of the MPE dispatcher so that you can understand the purpose of CMS. There are 5 dispatcher queues associated with MPE, AS, BS, CS, DS, and ES. For the sake of
arguement, you should never work with the AS or BS queus. The CS queue is the default for sessions, and the DS for batch, the ES queue is typically such a low priority that it is useless in it’s default state.
The lower the number in the priority of a queue, the higher precedence it gets from the CPU. Each queue represents a range of priorities, the CS queue is 152 to 200, the DS queue is 202 to 238, and the ES queue is 240 to 253. By
default when a session logs on it starts at the base priority of 152, as it uses CPU time its priority is lowered (the number gets higher) until one of the following events occurs:
1. A terminal read is issued. If this is the case, the transaction is completed and the process returns to its “base” priority of 152 until a new transaction is initiated by hitting return or enter.
2. The priority reached the “limit” of 200 if the “decay” options is on for the queue until a terminal read is issued.
3. The process has a resource that a higher priority process wants, and the higher priority process can’t do anything until it gets it. The lower priority process will be bumped up until it releases the resource.
For batch jobs in the DS and ES queues, the same basic rules apply, except batch jobs don’t issue any terminal reads, so they end up dropping to their limits immedialty and thrash around for CPU together. One way to avoid this is to set
the queue to “oscillate”, which will cause the process to go back to it’s base every time it reaches its limit.
I have seen shops where they throw all the jobs in the ES queue, and wonder why they never finish, or other shops put all their batch jobs in the CS queue, and have almost same result because everything is thrashing at the bottom of the
CS queue. The trick is to set up sub-queus that allow you to specify that different users or processes can work at different linear or cyclic priority ranges. This is where CMS comes into play.
CMS allows you to create what it calls a “Workgroup” which is basically a logically related group of processes that you want to be active at different times. See figure 1 for an example of the main screen with the file menu pulled down.
I should stop and mention at this point that CMS uses a really slick psuedo-window interface that uses pull down menus and pop-up windows, including context sensitive help, as seen in figure 2.
When configuring the Workgroup you can specify a “type” of “S” for sessions, “J” for jobs, or “A” for all sessions and jobs. Next a “level” can be defined, this is a value from 1 to 50, with 50 being the highest priority. This allows
you to cause one Workgroup to evaluate before another. Given how quickly everything happens, this is really going to have a marginal difference. Next is a feature that is really unique to CMS, this is a “Days” parameter. With this you
can specify all days, specific days of the week, or month, that the Workgroup should be active. Associated with this is the “Time” parameter, allowing you to limit a Workgroup to specific times.
Once a Workgroup is defined, you will want to add processes to the Workgroup, otherwise it is useless. You can control processes by either JOB/SESSION, Program, or LDEV. Programs and Job/Sessions can have wild cards anywhere in there
name, so @,AR.PROD would apply to all the users logged on with AR.PROD. See figure 3 for an example of an open configuration file.
After you enter the process you are concerned with, you can specify weather to “skip” it. This is basically an ignore function, so if in our previous example we didn’t want to affect MILES,AR.PROD, we would create an entry for him with
‘Y’ in ‘skip’ after we had defined @,AR.PROD. The next field is ‘queue’, and this lets you define either the default queue for the process, or a linear priority to run at, the valid entries are CS, DS, ES, 152-255. This keeps you from
getting up into the BS queue range and really fouling up the system.
Next is the “Boost%” field. This is where you can make CMS alter a process so that when it hits its limit, such as 200 (the bottom of the CS queue), it will be boosted by a certain percentage back up. A value of 100 would boost it all
the way back to 152. The “limit” field allows you to set arbitrary bottom ranges to a queue. You could set this to something like 170, so that your CS queue process now would range from 152 to 170, instead of 200. The implication here
is that in conjunction with Boost, you can create ultra high priority processes.
I like this next field, its ‘abort’. If you were creating a ‘session’ type workgroup, and you didn’t allow online compiles, you could specify that COB@.PUB.SYS would be aborted. In conjunction with the next field, CPU, you can specify
how many CPU seconds should elapse before you either take action on the priority, or abort the process.
Another nice feature of CMS is that you can launch, and kill Workgroups without bringing down and starting up their background job, this is in contrast to some of its competition.
Your only real problem in working with CMS is that it does require that you understand your environment to a certain degree. You don’t have to manage everything at once, but as you start to control things, the processes that are
uncontrolled will quickly start to become obvious. A nice companion to CMS would be a system monitoring tool like SOS or Glance.
Usability (also installation)
Technikal has done a really slick job of developing an installation routine. It is a Windows based program that will take advantage of either your Reflection or Minisoft terminal emulator to upload and install the software. If you are
a user of KLA/Express, it can even convert all of your configuration files for you automatically.
As mentioned earlier, the software uses a very slick Windows like interface running on a reguler terminal. It is very easy to set up and use once you learn how to navigate the software, which only takes a few minutes.
Reliability
CMS is rock solid in it’s handling of the dispatcher. The interface still had a few quirks in it, nothing catastrophic, just some key strokes weren’t being accounted for, all of which should be fixed long before you read this, maybe I
shouldn’t even have mentioned it.
Performance
CMS is only going to help your performance, not hurt it. There is an incredibly negligable impact on performance when CMS is doing it’s work. The interactive interface is pretty much instant, which is amazing when you look at the nice
psuedo-windowing that they are doing in the interface.
Supportability (including Doc)
Support is terrific, every time I called I got a human on the phone that immediatly answered my questions. The documentation. The documenation is very good, there is a nice explanation of the MPE dispatcher at the beginning, as well as
overview’s of how and why to use CMS. My only real problem with the documentation is that the tutorial is almost the last chapter of the book, it really should be at the front in my opinion.
While I was in the middle of the review I received an update that included an MS Windows help file, so you had a nice hypertext document to easily refer to without having to hunt around for where you left the manuals. I liked this
option a lot.
Summary
The only real problem with CSM, is with software like Speedware or AMAPS. The way you use CMS is to assign programs or users into workload groups, and control what dispatcher range they will use, and how they will decay. With Speedware, everything is in Speedware, there is no way to differentiate a program, AMAPS has the same type of problem because it has this weird job that does a CREATEPROCESS on all the ports, so there is nothing to distinguish them, you either have a hundred people running the Speedware program, or just one huge process tree. Technikal is working on a version that will let you control it by CPU consumption thresholds, which should help.
Almost all shops can really make use of this kind of granular dispatcher management. Very few people even bother to look at how they are tuned these days, and will go and get more memory, bigger CPU’s, etc, and they could have extended the life of the current environment with just a little work. If you are experiencing any sort of performance problems, you should at least give CMS a look. The folks at Technikal really understand the dispatcher, and how best to set things up, you’ll be amazed at the results.
At-a-Glance box
CMS version 1.00.A0
Technikal, Inc.
P.O. Box 14854
Clearwater, FL 34629
813-784-5976
FAX 813-784-5976
Call, write or FAX for information and/or a free demo.
$2,495 per copy, with support being $500 per site and one 74 page manual. There is a very attractive trade-in program for existing KLA/EXPRESS customers, as well as automatic conversion of configuration files.