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 HPs 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 years HP World. Im sure we all were drooling, I know I was, over David Greers 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 Im full of it or
goofed, or a horses behind, let me know. If something from
these columns helped you, let me know. If youve 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 email@example.com or
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. Weve 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 dont 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.
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 cant 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.
I know Ive gotten in the bad habit (and Ill bet Im
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.
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.]
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: Youll 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 theres 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
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
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 Id 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. Thats why I strongly recommend you set up your shell prompt and MPE prompt to show where you are. From one of my systems,
MON, JUN 25, 2001 3:25 PM </SYSADMIN/HPXEQ>
In this case, Im signed on to
the computer SASHA as MGR.SYSADMIN in the group PUB, but my CWD is
John Burke is the editor of the NewsWires HiddenValue and net.digest columns and has more than 20 years experience managing HP 3000s.
Copyright The 3000 NewsWire. All rights reserved.