net.digest February 2003

February 2003

Net.digest summarizes helpful technical discussions on the HP 3000 Internet newsgroup and mailing list. Advice here is offered on a best-effort, Good Samaritan basis. Test these concepts for yourself before applying them to your HP 3000s.

Edited by John Burke

After several months in the doldrums, the technical traffic really picked up on 3000-L. In fact, I picked up enough material for several months’ worth of 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. Rosenblatt himself punned to connect the poet to HP 3000 disk drive enclosures. In response to someone’s questioning Jamaican pepper in the haggis recipe, Rosenblatt 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 spot something on 3000-L and would like someone to elaborate on what was discussed, let me know. You can reach me at john@burke-consulting.com.

You may still be able to get HP support on older equipment

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 if 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.

Configuring 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 LIMIT BASE 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 3000-L, along 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-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 HP 3000 architect 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 it’s 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.”

The MPE::IMAGE Perl module has a new maintainer

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 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, 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, as well as another article about the free Unix Transition Training HP is offering its HP 3000 customers and partners.

I just wish in all these Webcasts, white papers and Tours someone at HP would have the cajones to say the following: “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. It’s difficult to compute indirect expenses associated with revenue-generating projects which stand still while a migration is performed.”

That’s not all. I’d like HP to say, “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 event. 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.

Advanced Telnet is now available on MPE/iX 7.5

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.

John Burke is the editor of the NewsWire’s HiddenValue and net.digest columns and has more than 20 years’ experience managing HP 3000s.