MB Foster Associates 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

After a slow month, the off-topic and wildly off-topic postings returned in force in June. There was the report of the HP presentation in Detroit on a delivery agent for its document router that would “run on any operating system.” Of course the presenter had never heard of MPE or the HP e3000. Sigh. Then there was the thread about HP’s revised Web site “losing” the link to the HP e3000. This thread, of course, then beget a lengthy thread on whether we need a new slogan for this year’s HP World. I’m sure we all were drooling, I know I was, over David Greer’s planned year-long sailing trip in the Mediterranean. And, in an amazing bit of me-too-ism, several weeks after CSY launched the Invent3K server access program, IBM made a server available via the Internet for access by people interested in working with Linux.

There was the yearly whining and hand wringing over the cost of HP World. Apparently everyone except Interex thinks it is too expensive, at least in part because of the many pointless and expensive events that have nothing to do with HP or computing. And in a really long thread we debated whether the “e” in HP e3000 was catching on. The consensus? No. June also saw discussions about the 50th anniversary of UNIVAC I, a spectacular solar eclipse over Africa, neutrinos changing flavor and thus poking a hole in the Standard Model of the Universe, and the closest approach of Mars in many years.

I love this list.

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 3000-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@paccoast.com or john@burke-consulting.com.

SYSSTART, I thought I knew ye [Continued]

Last month I discussed what you can and cannot do in SYSSTART. I ended the discussion by exclaiming “Wait a minute. I thought NSCONTROL and NETCONTROL could not be called from SYSSTART? To be continued…” in reference to both NSCONTROL and NETCONTROL showing up on the list of commands supported under SYSSTART. We’ve all been taught (right?) that these commands cannot be executed from SYSSTART and that the “right” way to start up your network is from a batch job streamed by SYSSTART. So, what gives?

From Jeff Vance: “I double checked the code and NETCONTROL and NSCONTROL are in the list of supported commands. However, I tried these commands on a test system and they did NOT work. So, PROGEN accepted the commands but for some other reason they did not execute.”

Doug Werth supplied part of the answer: “NETCONTROL and NSCONTROL don’t actually do anything themselves. They send a message to a background process (NETCP.NET.SYS I think) to execute. Due to timing issues at boot time NETCP is not ready to handle commands at the moment SYSSTART executes so the task of starting the network is usually put into a job [editor: or OPERATOR.SYS udc] instead.”

Mel Reese then passed on information about an undocumented option that “might” start up the network directly from SYSSTART: “To Use NETCONTROL and NSCONTROL in SYSSTART, add the “OVERRIDE” option to the command. I have no idea where this is documented, but it works and has worked for at least 7 years.

:NETCONTROL START;NET=LAN1;OVERRIDE
:NSCONTROL START;OVERRIDE

“The NETCP process timing could still be an issue so HP officially recommends you start the network after the console is logged on or from a job streamed by SYSSTART.”

Finally, James Hofmeister set us all straight on what is going on and why we should continue to start the network the way we always have [Editor: this is interesting stuff, so I am going to quote James liberally]: “Let me give you some feedback on the OVERRIDE option. The key point is as Mel mentioned above ‘I have no idea where this is documented’ because it is not documented for customer use, i.e. not supported for customer use.

“I use the OVERRIDE function infrequently because it avoids version checking of the modules reported by :NMMAINT,3. This is useful from a support perspective if you want to isolate to and install a single fix that would intentionally result in a version mismatch, but was valid for internal ‘testing’ purposes. This is something you would never want to do on a production machine, especially in the circumstance of the multilayer protocol network code.

“In a few cases ‘:NSCONTROL START;OVERRIDE’ is used when the purchased NS product is inadvertently not included with the SUBSYS tape on an update to a new OS. ‘:NSCONTROL START;OVERRIDE’ may be recommended by HP to support inbound PC connections while the SUBSYS tape with the remainder of the NS-Services is delivered.

“I know of no valid reasons that OVERRIDE is appropriate for a production machine. I would consider it dangerous to execute the OVERRIDE option as the default and risk the possibility of data loss, data corruption, a system abort or some other unexpected error due to a protocol module not started as a result of miss-matched or corrupt network code modules. The version mismatch message when attempting to start the networks is much less painful than the above unexpected failures or corruption.

“I can’t say it enough. It is important for ‘NETCONTROL START’ to perform its version check after every NS-Transport ‘NST’ patch is installed. If you use the OVERRIDE option, this is not happening.”

James then went on to explain that ‘NETCONTROL START’ may even work sometimes without OVERRIDE, it just depends upon whether the NETCP system process is ready to listen when it encounters NETCONTROL. He ends, however, by re-iterating: “Put your ‘NETCONTROL START’ in a separate job stream which is streamed by SYSSTART. It is much preferable to check the $STDLIST of the job stream to determine why your network did not start than to read a memory dump.”

Something to watch for when upgrading to MPE/iX 7.0

From Paul Edwards: “In the MPE/iX System Software Maintenance Manual 7.0, the value of 120,000 sectors must be changed to conform to the value returned from CHECKSLT.MPEXL.TELESUP option 7, which is 170,000 sectors in my case. It could cause an update failure if the size of AXLDEV1 is too small. The errors are on page 72, Chapter 3, Contiguous Disk Space Requirements; page 73, Chapter 3, Disk Space Error Messages; and page 76, Chapter 4, paragraph 2, in the BUILD AXLDEV1 command. I use 180,000 sectors as my value during updates to make sure I have enough space.”

Thanks Paul. I know I’ve gotten in the bad habit (and I’ll bet I’m not the only one) of not running option 7 and just running option 1 (check tape) and then automatically using 120,000 sectors for AXLDEV1. You may have saved others and me a lot of grief.

Try to wrap your mind around this

Think of the music played during the introduction to the old Twilight Zone TV show to get in the mood for this. In April 2002, support ends for MPE/iX 6.0. MPE/iX 6.0 is the last OS to support HP-IB peripherals. The HP-IB card is supported in the 9x8 and 99x systems, many of which do not have an EOS date until 2006. Now, here is the good part. The EOS for the HP-IB card (A1747A) is August 2004. [Note: Chris Gauthier supplied much of this information as part of his reply to a thread on EOS dates.]

Don’t take “No” for an answer

As part of his planning process for upgrading from MPE/iX 6.0 to MPE/iX 6.5 PP2, someone asked if he had all the tapes he needed and went on to list the tapes he had. Chris Bartram suggested: “You’ll save yourself some hassle and potential problems if you also call the HPRC and order a tape with all the current reactive patches. You can download them off the Internet, but there’s a bunch (73 on the last tape I got) and it can save you several hours by getting a tape of reactive patches.” [Note that Patch/iX will be able to qualify which patches belong on your system so that this tape does not have to be customized.]
Good advice, Chris. In fact, pretty standard advice for a couple of years now. If your e3000 is connected to the Internet, you can of course use Mark Bixby’s Patchman script to make the download of multiple patches reasonably painless. But, if your e3000 is not connected to the Internet, or you just do not have the time, a tape of patches is definitely the way to go, especially when there are more than just a couple of patches.

Two people then replied that when they called the HPRC and asked for a tape of reactive patches they were directed to a Web site and told to pick out the patches that apply. This was of course an unacceptable response, as numerous people pointed out, if for no other reason then that any particular patch may cover numerous fixes that are not discussed in the brief description. These responses prompted the original questioner to try again: “When I got a similar response as before, I read the lucky CE some of your responses. After waiting just a few minutes while he discussed this with his manager, he told me that the problem was largely due to miscommunication within the HPRC. His manager was in the process of informing the entire scattered staff that it would be okay to issue such tapes.”

The 3000-L list comes through again.

To ‘.’ — or not to ‘.’

Here was the question that started the thread: Is it dangerous to put ‘.’ in your path on MPE/iX? The person who posed the question went on to explain how this was frowned on in Unix environments because it creates susceptibility to Trojan horses. The general feeling was that it was probably OK on MPE systems. Or, as Gavin Scott said, tongue firmly in cheek, “there may be other reasons to omit ‘.’ from your path, but if you seriously have to worry about your users leaving little land mines out for you then I’d recommend getting some new users.”

This got me to thinking, always a dangerous thing. My feeling is that it is generally an OK thing to put ‘.’ in your path on MPE systems since you are probably more likely to shoot yourself in the foot than fall victim to a Trojan horse. Why? Well, how many times have you found yourself wondering exactly where you are? This is especially true if you keep multiple sessions open at the same time. That’s why I strongly recommend you set up your shell prompt and MPE prompt to show where you are. From one of my systems,

<SASHA: JPB,MGR.SYSADMIN,PUB> MON, JUN 25, 2001 3:25 PM </SYSADMIN/HPXEQ>
[13]:sh
…
[128] /SYSADMIN/HPXEQ $

In this case, I’m signed on to the computer SASHA as MGR.SYSADMIN in the group PUB, but my CWD is HPXEQ.
Why am I obsessive about this and why do I try to force similar behavior on other people? Several years ago a co-worker was moving an MPE group to a different volume set and issued the command: PURGEGROUP PUB. As you might expect, he had several session windows open on his PC. Only after he was told by the system that the group could not be completely purged because some files were in use did he discover that he issued the command from a session where he had logged on as MANAGER.SYS! Believe it or not, he did the same thing on another system several months after the first episode. Ugly does not begin to describe the mess this created. Oh, if you are wondering why he was still around to do it a second time? The person in question was my boss. I have since taken over all these tasks from him and strongly discouraged him from signing on as MANAGER.SYS.

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