CSI Sponsor Message

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

I’m back — sort of like the rash you can never quite get rid of. After a year of doing something else on the side in addition to my regular 80-hour a week job, I’m back doing HiddenValue and net.digest, two things I thoroughly enjoy. Not that I was out of touch; I’ve been following the HP3000-L mailing list and newsgroup, and even occasionally contributing. So I know what you were doing last summer!

In a month with over 1,500 postings, we were treated to discussions about odd names, HP 3000 games, the government taxing communications, and the inevitable, bi-annual how-do-I-reset-the-clock ruminations. Oh, yes — and a wealth of technical commentary too great to cover completely anywhere. Even here. Here are some snippets that caught my eye, though.

No need to call the movers, we can do it ourselves

Quite a bit of traffic over the last few months dealt with how to move software packages or any collection of files from one HP 3000 system to another over the Internet. Let’s see, there was uhaul, mover (but you have to make sure you use compatible versions), lzw, tar, zip, qzip, MPE TurboSTORE to disk (but you have to have the 7x24 online version to create the initial disk package), etc. And of course you also had to worry about whether a particular method could handle “special” MPE files (TurboIMAGE, KSAM, etc.).

Gary Biggs came to the rescue with the following post:

OK, I’m sick and tired of the complaining around here. If you have an Internet-connected 3000 or you know how to transfer files from the Internet to your HP 3000, you might like to try the following.

Late last year, I decided to try to develop a mechanism that would automatically deliver MPE store media easily across the Internet. The results of this project have been highly successful. To date, I have able to deliver store tapes, reactive patches, power patches and the SLT to computers across both our local net and the BIG net.

To get started, you will need a GETPKG UDC.

Follow this link: www.biggs.dallas.tx.us/GETPKG.TX T, to obtain the UDC. Use an ASCII transfer method to place it in a text file on your 3000. The link www.biggs.dallas.tx.us/GETPKGI. TXT contains the instructions.

Stan Sieler followed up almost immediately with, “It works!”

[Editor’s note: The only other thing you need is version 2.2 of the TAPECOPY utility, which is available on CSY’s Jazz Web site and is co-authored by Lars Appel and Kevin Miller.]

Halt right there — no need to power-cycle that DTC

This would normally be an item for HiddenValue. However, since I was not “listening” to the list when the original posts were made and have something useful to contribute to the answer...

Q: I’m about to switch from an Series 937 on MPE/iX 5.0 to a Series 939 on MPE/iX 5.5. The 939 will be a complete replacement of the 937, using the same IP address, DTCs etc. We must get the DTCs now on the 937 to work with the 939. Is it possible to configure these DTCs into the nmconfig of the 939 — and after shutdown of the 937 boot up the 939 and do a sysdiag/termdsm reset on the DTCs to get them to “load” from the 939? I’m not sure you can reset a DTC that hasn’t been “seen” before by the system. The problem is that the DTCs are located in an area I don’t have ready access to, so power-cycling them is not an option, unless absolutely necessary.

Howard Hoxsie replied. “I did the same sort of thing last fall. I shut down our old 987, moved the cable connected to the dedicated LAN for DTCs to the LANIC on the new 997 (where the NMCONF had been copied over from the 987 and slightly tweaked), rebooted, and then used termdsm to force down the config/reset for each DTC. Worked like a charm for our remote DTCs and I didn’t need to power-cycle. Hope this helps.”

I’ll add: that there were several other suggestions, some of which relied heavily on the Rube Goldberg approach to system administration. Clearly, both the original questioner and Mr. Hoxsie were using host-based DTC management as opposed to OpenView DTC Manager. (For example, TERMDSM does nothing unless you use host-based DTC management.) I’d like to take this opportunity to pass along a trick I learned when doing a similar system upgrade and which I have used successfully several times since after replacing an MFIO board (which contains the LANIC). I believe it will work with both host-based and OV DTC MGR-based DTC management.

Whether swapping boxes or replacing a LANIC, since you are not changing the DTC configuration, there is really no reason why you should have to download a new one. In my case I had over 50 DTCs, so the thought of trying to download a new configuration to all 50+ DTCs made my knees weak. The real problem here is not the DTC configuration, but the fact that each DTC still has the HP 3000 nodename resolved in cache to the LAN address (MAC) of the old system (or old LANIC actually). Resetting each DTC with TERMDSM or OV DTC MGR or power-cycling each will, of course, take care of this. But there is an easier way, especially if network traffic is a concern (like going out over a WAN).

Have the first user attempting to connect to the host from each DTC enter at the DTC> prompt the following:

c nodename -d

where “nodename” is the machine name. The “-d” option causes the DTC to flush its cache table of nodenames to LAN addresses. Once this is done, the DTC will re-resolve the name of the host to the new LAN address. No muss, no fuss, and no downloads. Of course, if you do not have any terminals or PCs connected to the DTC (i.e. printers only), then you are going to have to force a download with TERMDSM or OV DTC MGR, or power-cycle the DTC.

Finally, thanks for that tip go to Kelly Trayer, the Response Center engineer who taught it to me two years ago.

From the “Now why didn’t I think of that?” department

Robert Schlosser, in going over the SIGMPE/SIGSYSMAN ballot, noticed the request for the inetd job/process to run in the CS queue and passed along a great tip for when you want some process within a job to run at a priority other than that of the job itself:

You can ensure that the job runs in the CS queue no matter what is on the job card by inserting the following line before the execution of inetd:

!ALTPROC ;PIN=0;PRI=CS

This alters your current process (the CI) to the CS queue. Anything that is launched by the CI is then launched in the CS queue. I’ve used this technique for various tasks and it works well.

[Editor’s note: This form of the command only requires OP capability. And if you have SM capability and/or the HP Workload Manager product, there are lots of other things you can do.]

Jeff Kell, Chairman of SIGMPE, chimed in with some history and rationale for the request, as well as kudos for Robert’s tip:

Several workarounds were discussed at IPROF. The item remains on the ballot simply to point out that it is a problem area, especially for the many sites that may not be aware of the issues caused by inetd running in the default DS queue. I was thinking that a clean fix would be for inetd to issue a GETPRIORITY() call, although I must admit, I like your workaround even better.

I don’t care about the mechanics of it, as long as it is fixed so that it works “out of the box”. It is one of those very low effort fixes (IMHO) that CSY should just “do” without us casting valuable votes on it since there are such simple workarounds.

[Editor’s note: Many sites that have avoided inetd up to now will have to start using it when they update to MPE/iX 6.0, since FTP will only run under inetd.]

Another issue came up at IPROF that perhaps we should extend the format of inetd.conf to allow for a priority to be specified along with the services monitored so that telnet could get CS priority, for example, while FTP might get DS priority. The ballot item also mentions this.

Save a tree

This too started out as a HiddenValue item, but so many people contributed decent ideas it became unwieldy.

Q: Like many shops, we transfer the System Console to a printing terminal attached to a DTC. The problem we have is that when this “console” runs out of paper with no operators around, the console output buffer fills and the system hangs. Are there any configuration changes we can make so the system will keep working even if it can’t output console messages to the printing console?

Bill Lancaster replied, “Actually, I think most shops don’t print hardcopy for the console. What I’ve seen most is that shops turn on console logging (you can do this in SYSGEN, or SYSLOG from Allegro) and extract from the log files occasionally and print only what they need, which is usually nothing.”

Joe Geiser added: “Although I know of shops that do have printers hooked up to their consoles via the printer port (not nailed on a DTC, but on the console’s printer port in the back), it is the preference of most shops to extract console information from the log files when it’s needed.”

Ted Ashton also added: “We keep a month of console logs, and though I don’t go through them trying to catch folks, they have come in handy when tracing problems or checking up on what happened. Our console log is via ‘log bottom’ on the terminal that has the disadvantage that we have to turn it back on after loss of power (fairly rare), but otherwise we’ve had no trouble with it.”

Roger Hall suggested saving a tree by using a PC running a terminal emulator and doing a LOG BOTTOM to the PC’s disk drive. Of course, he added, you should make sure the PC is on a UPS.

Mike Hornsby noted that one of the ‘features’ of MPE/iX 6.0 is that Easytime is now bundled in. Easytime was created back in the Micro 3000 days to allow the console to be used as a regular terminal. On an 8-user system, dedicating a terminal to the console was a bit ridiculous. The Console Management feature of Easytime may be an attractive alternative for console printing.

Finally, Lars Appel suggested:

Let me share what typically helps me to get some reasonably readable console log from the system logfiles.

:SYSDIAG

DUI> LOGTOOL

LOGTOOL> STATUS DETAIL

(pick the interesting log file numbers based on “starts at” timestamps)

LOGTOOL> SUMMARIZE LOG=123/456

(just to get a quick overview about events contained in those logfiles)

LOGTOOL> LIST LOG=123/456 TYPE=115 OUT=myfile1

(this one extracts type 115 events, i.e. console messages to a disc file)

LOGTOOL> EXIT

DUI> EXIT

:FCOPY FROM=myfile1.diag.sys;TO=myfile2.diag.sys;NEW;SUBSET=”(OUTPUT)”

Now print myfile2 for the lines that look pretty much like what scrolled along the console in the past (ignoring the (OUTPUT) prefix on each line). Or check out myfile1 in case you want all the details that are reported by LOGTOOL LIST (e.g. associated PIN numbers, user, acct, etc.).

Don’t forget to purge myfile1 and myfile2 in DIAG.SYS when done.

[Editor’s note: Be sure also to check out CONSLOG from the CSL. I use it to great advantage with console logging turned on. But it admittedly does little good if the system is down and the log files unavailable. And, if you have a very active system, you can chew up disk space rather quickly.]