After several months
in the doldrums, the technical traffic really picked up on HP3000-L. In fact, I
have enough material for several months’ worth of “Hidden Value” and
“net.digest”. As usual though, there were plenty of off-topic and wildly
off-topic threads. Several of the off-topic threads became pun-fests. My
favorites came from a thread that started out with Joseph Rosenblatt offering
the recipe for haggis in honor of the birthday of Scotland’s National Poet,
Robert Burns. Joseph himself, in response to someone’s questioning Jamaican pepper in
the recipe noted, “Since
Jamaican pepper is hot it could be swapped for other peppers in the spice rack.
This is the first case of hot swappable Jamaicas.” But my favorite came from Neil
Harvey in describing haggis, “it sounds offal at first, but I assure you, it's
delicious”.
As always, I would like to hear from readers of net.digest and Hidden Value. Even negative comments are welcome. If you think I’m full of it or goofed, or a horse's behind, let me know. If something from these columns helped you, let me know. If you’ve got an idea for something you think I missed, let me know. If you spot something on HP3000-L and would like someone to elaborate on what was discussed, let me know. Are you seeing a pattern here? You can reach me at john@burke-consulting.com.
I’ve seen a number of reports indicating that some people have been able
to contract with their local HP support organization to support older equipment
(9x7s for example). If you do not want to use a third party maintenance company
(note there are several excellent ones) or there is no third party maintainer
covering your area, it is worth giving your local HP support group a call. You
will have to be persistent. I understand the decisions are made on a
case-by-case basis, based upon parts supply. You will also have to understand
that if the local organization cannot fix the problem, it will not be escalated
up the line. For some, though, this will be a good solution.
Queues
Do a SHOWQ ;STATUS command on a system that has never had the queues
modified and you will probably see something like this:
------QUANTUM-------
QUEUE
BASE LIMIT MIN
MAX ACTUAL BOOST
TIMESLICE
-----
---- ----- ---
--- ------ -----
---------
CQ 152
200 1 2000 1 DECAY 200
DQ 202
238 2000 2000
2000 DECAY 200
EQ 240
253 2000 2000
2000 DECAY 200
This is exactly the display posted on HP3000-L with the following
question: “I would like to slow
jobs down in the ‘E’ queue. How should I change the ‘E’ queue?” Nobody was
quite sure what he meant, but it did start an interesting thread (if somewhat
long) on queue configuration, most of which is reproduced here. [Note that if
you have no current performance problems, you probably do not want to fool
around with your queue settings. You might, however, want to file this away for
the inevitable time when you do have performance issues.]
Keven Miller
wondered: "Wouldn't changing the timeslice on EQ to a smaller value (like
100) make EQ processes relinquish the CPU more often?"
John
Clogg offered this analysis: "The processes in the E subqueue are already
running at a lower priority than any other processes on the system. This means
that they are getting CPU resources only if no other processes need them. Given
that situation, why would you want to impede them any further? The EQ jobs are
unlikely to be causing any significant degradation to other processes. That is
true for CPU, anyway. If you are seeing other resource problems due to jobs in
the C queue, such as disc I/O or memory pressure, you will not be able to
alleviate them through changes to the TUNE settings. You would have better
success by limiting the number of jobs. Recent versions of the OS (starting
with either 6.0 or 6.5, I don't remember which) allow you to define multiple job
queues. You could define a separate queue for the jobs in the E subqueue, and
set a limit of 1 or 2 for that queue.
“The
only good way to accomplish your goal of slowing down the EQ jobs is to use
Workload Manager to limit the amount of CPU these jobs are permitted to
consume. I would caution against the suggestion to alter the timeslice. That is
likely to increase dispatcher overhead, without significantly contributing to
your stated goal. Workload Manager is an extra-cost product, so it might not be
available on your system.”
Gary
Jackson elaborated on one of John Clogg’s suggestions: "If you are having
problems with multiple jobs in the E queue competing for resources, how about
creating a NEWJOBQ and making all of your E queue jobs run in that jobqueue.
Limit it to one at time."
Tracy
Johnson offered the configuration his site uses: "Without going into the
newfangled customized queuing commands, the following has served me well:
"1
Shorten the C Queue Quantum. (This doesn't slow down the E Queue, but provides
online users with a smaller slice of the pie.) I suspect your online users are
competing on an equal basis with your batch jobs. I note the ACTUAL value
indicates they aren't using that much. I also figure your online users are the
ones complaining, wink, batch processes usually don't whine as much: tune
cq=152,200,32,128,,100
"2
Shorten the D Queue Quantum. (Another smaller slice of the quantum for your
High Priority Batch jobs, but gives a bigger timeslice.): tune
dq=202,238,1000,1000,,1000
"3
Let the MIN/MAX of the E Queue Vary. (This leaves your E Queue much as it was,
giving it a bigger timeslice. The variance will allow it to quit sooner if it
does not need the resource.): tune eq=240,253,1000,2000,,2000
"Note
while I shorten the C queue, I increase the timeslice for both D and E. Although this gives bigger 'chunks' to batch
processes, they will be allocated less frequently and give more time for your
batch to finish what it is doing. (E still has to wait for C and D to open up a
hole before E gets its share.)
"4.
Put the above lines in your SYSSTART.PUB.SYS file."
Jeff
Kell noted: "I would only add that if you are experiencing absolute
starvation of a queue, especially the D and E queues, then make them overlap in
priority a bit (e.g., dq=202,240 eq=230,253) and use OSCILLATE. This is the
only way to insure one won't completely starve another."
John
Clogg chimed back in with: "Actually, even this trick won't guarantee that
the E queue will not get completely starved. The reason is that the priority of
a process doesn't oscillate to the top priority of the circular subqueue until
it degrades to the lowest priority. In Jeff's example, once a process in the E
queue degrades to a priority lower (higher number) than 240, it can get starved
to the point that it never goes any further and can't oscillate. Still, this
doesn't happen often, and OSCILLATE has actually made the practice of
overlapping queues useful."
The
final word came from Steve Macsisak: "Are you having response time
problems. With the current settings the EQ can only get CPU if the CQ and DQ
are not using all the CPU. The catch might be that the EQ jobs have the same
databases open as the CQ jobs and they get their priority boosted when a CQ or
DQ job locks (put/delete semaphore most likely). Otherwise you have the correct
settings for favoring the CQ and DQ. For good response time its normally best
to have shorter time slices for all of the queues.
"Why
do you want to slow down the E queue, the system was designed to favor the highest
priority processes (CQ with your settings) and then give everything else to the
lower priority processes (DQ then EQ) with your settings. If you really want to
slow down the EQ processes, write a program that does a loop and pauses
occasionally (experiment with best value) and then put it in the DQ (if that's
higher priority then EQ).
"Most
recommendations about queue settings are really trying to keep DQ and EQ
starvation from happening and with your settings if the EQ is running then
starvation is not occurring."
Dave Oksenr reports that he is taking over from the original author, Ted
Ashton and has some plans: “This
originated because I'll be adding support for HP-UX, running against HP
Eloquence, and offered to send him the changes. When he said that he wouldn't
be able to do any maintenance, we agreed that I would take over.
“Currently,
searching for the module on the web page search.cpan.org doesn't find the
module, but if you use the CPAN module in interactive mode, it finds the new
location, D/DO/DOKSNER/MPE-IMAGE-0.98a.tar.gz. Also, you can go directly to it
on the web at
http://www.cpan.org/authors/id/D/DO/DOKSNER/MPE-IMAGE-0.98a.tar.gz
“Feel free to
write me if you have any questions at dave-perl@case.net.”
What I’d like HP to say
Allow me to vent
a little. Since November 14, 2001 I’ve attended virtually every event and
webcast that HP has offered where it discussed both its decision to end sales
and support of the HP 3000 and its plans for its customers and partners.
Elsewhere in this issue is an article about the Transition Tour and another
article about the free Transition Training HP is offering its HP 3000 customers
and partners. I just wish in all these Transition Webcasts, Transition White
Papers and Transition Tours someone at HP would have the cajones to say
"HP made a business decision in 2001 to end production of the HP e3000 and
renege on its promise to port MPE to Itanium. Speaking for HP, we recognize
that what we felt was good for HP is not necessarily good for all our customers
and partners. One unfortunate result of our decision is it really put the
screws to many longtime customers and partners, disrupting businesses and
careers in the process. HP’s decision is forcing on these customers and
partners unplanned direct expenses in the hundreds of thousands, if not
millions, of dollars and difficult to compute indirect expenses associated with
revenue generating projects standing still while a migration is performed. We
realize there is no way we can compensate these customers and partners for the
effect our decision has had, but we are trying to smooth the way as much as
possible with webcasts, free training, discounts, etc. in the hope that some
percentage of customers and partners will stay with HP."
Actually, HP
ought to say this at the start of every Webcast, White Paper, Migration Ad,
Transition Tour event, etc. It would not change anything, of course, but at least
I could include HP again in my list of companies I admire for their honesty.
James Hofmeister reported in January that patch PTDGDT9 for C.75.00 (MPE/iX 7.5) is now in
General Release and can be downloaded for the ITRC. Advanced Telnet is really
not much more than the old half-duplex, where the character input at the
terminal (or terminal emulator such as QCTerm) is not echoed back from the
host. In a LAN environment, there generally is no latency in the echo; however,
when communicating over the Internet the latency can be on the order of
seconds, making it almost impossible to work. QCTerm, for example, is designed
to work well with Advanced Telnet, providing smooth telnet communication across
the Internet.