Net.digest summarizes helpful technical discussions on the comp.sys.hp.mpe Internet newsgroup and 3000-L 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

This has absolutely got to be a record: 1,778 postings to 3000-L during the four weeks between September 25 through October 22. Maybe I need to stop counting postings and just accept that we are a very vocal community. And getting more so every month. The great thing about 3000-L is that it is never boring, and only rarely annoying. Mixed with more good technical content then we could ever hope to publish each month are some of the most fascinating off-topic threads you are likely to find anywhere.

Among the more interesting off-topic nuggets this month was the origin of the name of the HP 3000 division’s Jazz server (jazz.external.hp.com). It turns out that it is in honor of and derived from the initials (JAS) of the manager of the team that did the first port of a Web server to MPE/iX, Jerri Anne Smith. On the more esoteric side, there was a long, fascinating thread about tacking against the solar wind.

Bringing us all back to earth, there was a new chapter in the Mac vs. Windows saga (or soap opera, I’m never sure which) and more on what constitutes a legacy system. [I still like the “any system that works” definition; especially after someone reported seeing a blurb from a Chicago consultancy describing Oracle as a legacy system.] There were threads on the latest non-mention of the HP e3000 by HP’s CEO, and the announcement that HP bought the garage where it all started for a Silicon Valley bargain rate of $1.7 million (who knew HP did not already own the garage?). Additionally, there was a thread on re-branding of all IBM’s servers to the “eServer” (will we see a HP e9000?) and, finally, but definitely not exhaustively, there was a great Wirt Atmar story. You can look it up on the 3000-L archives at raven.utc.edu/archives/3000-L.html. Just look for the words “Gorilla” and “escapes” in the subject.

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 at john.burke@paccoast.com.

First, a correction

In August, in a section titled “SYSSTART and STARTSESS”, I indirectly quoted Lars Appel in this column: “ Lars Appel noted that the undocumented SET SECURE directive within EDITOR would preserve the security matrix for the file you are editing.” I added the word “undocumented” to Lars’ tip because I could not find the SET SECURE directive in the manual or online HELP. In a private message, Lars has pointed out to me that this is actually documented in the MPE/iX 5.0 Communicator. We have since agreed that “poorly documented” might have been a better choice (this is where, if my editor allowed it, I’d place a smiley face emoticon).

Consider this before moving to MPE/iX 6.5, Part I

Many sites with multiple machines routinely upgrade their test and development machines to the latest version of MPE/iX before upgrading their production machines. This, even though “In general, HP does not guarantee that an application can be developed on one release of MPE/iX and then executed on an earlier release without change.” (Communicator 3000 MPE/iX Release 6.5) This is so-called backward compatibility, not forward compatibility, which HP has always supported: “Hewlett-Packard strives to maintain forward compatibility from one release of MPE to the next. MPE/iX 6.5 is no exception. Applications developed on previous releases of MPE/iX should continue to run without needing to be recompiled or relinked.”

Those of us who take this test/development-machine first route will usually keep a copy of the old compilers and studiously avoid using new features until the production machines are updated. Generally this has worked, but MPE/iX 6.5 may cause problems unless you are very careful. The MPE/iX 6.5 Communicator has an Article titled “Compatibility Considerations for COBOL and C” you should read carefully if you plan to upgrade your development machine to MPE/iX 6.5 before upgrading production.

According to the Communicator article, “seven new routines were added to the Millicode libraries … to perform highly optimized arithmetic operations on 64-bit integers.” Furthermore, the “COBOL II/iX compiler was updated to generate code that takes advantage of the new 64-bit Millicode routines.”

There was some confusion expressed on 3000-L over what this meant; however, the following paragraphs for the same Communicator article seem to explain the situation, at least to my satisfaction:

“Backward compatibility for COBOL II/iX executable programs (NMPRGs) and executable libraries (NMXLs) should not be a problem. If your COBOL code generates calls to any of the new Millicode routines, those routines will be copied from the Millicode library and bound into your program or XL. The absence of the latest Millicode library on the target machine is not a problem, because the Millicode library is a relocatable library and is not accessed at run time.

“However, if you compile a COBOL II/iX program on an MPE/iX 6.5 system and try to link it on a pre-6.5 system, you may have unresolved externals because of calls to the new Millicode routines. These unresolved externals might be reported at link time, but it is possible that the problem would not show up until load time, with unrelated errors reported by the RUN command. The recommended procedure is to link on the 6.5 system, where the latest Millicode library is available.”

In other words, if you compile and link on a 6.5 system, the resultant binary will probably work on a 5.5 or 6.0 system. But there are no guarantees. C/iX has additional considerations for backward compatibility. Check the Communicator.

Something to consider before moving to MPE/iX 6.5, Part II

Michael Hurdle passed along the following to 3000-L (I’m including as much as possible of the original posting given space limitations — I suggest you look up the complete text in the 3000-L archives because this is IMPORTANT.):

“I was provided the following information from my HP Account Support Engineer yesterday regarding issues involving updating to MPE/iX 6.5. Has anybody else seen these issues surface? If you haven’t already updated to MPE/iX 6.5, it would be a good idea to read this carefully:

• Customers with Nike disks configured as LDEV 2, 3, etc. will see an AVR error during START NORECOVERY on 6.5 and these disks will not mount. A fix from the 5.5 patch MPEKXT8 did not make it into 6.5. A 6.5 patch, MPEKXD1, has been created to address this issue. However, MPEKXD1 can only be installed after 6.5 is up and running, so a special binary patch needs to be installed to allow the disks to mount when booting 6.5.

• Fast/Wide SCSI device adapter firmware can’t be updated after moving to 6.5. This may not impact the customer immediately, but if they need to update it later they will find that FWSCSIPB does not work properly on 6.5 (CR 8606144043). They will need to remove the device adapters from the 6.5 system and take them to a 5.5 or 6.0 system to perform the update. All FWSCSI DA’s should be updated to revision 3944 firmware prior to updating to 6.5 so this problem can be avoided.

Recommendations for addressing these two issues:

The procedures that need to be done for the 6.5 systems that have a Nike disk configured as LDEV 2 (and maybe others) are as follows:

1. Test the remote console (parallel console) facility prior to starting the update process.

2. Perform update from 6.5 CSLT. Do not perform START NORECOVERY.

3. HP will establish remote console (parallel console) and use the passworded utility, SADPATCH, to install a binary patch to the START program. An alternative is to have a HP person onsite to perform the binary patch since this is a passworded utility.

4. A START NORECOVERY can be performed and all disks should mount.

5. Install beta patch MPEKXD1 (A). Update from the CSLT created, but do not perform START NORECOVERY.

6. HP will establish remote console (parallel console) and use the passworded utility, SADPATCH, to remove the binary patch that was installed in step 2.

7. A START NORECOVERY can be performed and all disks should mount.

8. The customer should create a new CSLT tape reflecting installation of the MPEKXD1 fix along with removal of the special binary fix.

For the FWSCSI device adapter firmware issue, one option is to notify a CE and request that they arrange to acquire the firmware update file and perform the update. All device adapters should be updated to this firmware level. The CE can do the update either remotely or onsite. An alternative would be to request that the response center assist remotely. The system needs to be idle during the update. It is not necessary to be logged onto the remote console to perform this function. The update is performed using the FWSCSIPB utility.

The dreaded “NETWORK PROBLEM; Gateway redirects severe”

This comes up often enough that I thought I should recount a recent series of postings that ties several things together. A customer posted the following:

Is there anything in the message below I can use to determine what is being mis-routed? Our network people here say that all their equipment is configured correctly. Some days I get little or no gateway messages and other days they just roll off the console like ticker tape. Here’s the message:

SYS-A:** NETXPORT IP : NETWORK PROBLEM; Gateway redirects severe

- Loc: 215; Class: 2; Parm= $A1C37920; PortID: $FFFFF972

From Darryl Coombs came the following reply [Note his tip on how to interpret the PARM= value]:

I had the same problem not long ago. If you convert the PARM= from hex to decimal you get the IP 161.195.121.32, which should be the router that your system is having trouble with. My problem was that the routing table was not configured correctly in NMMGR. A network was set up on the wrong gateway.

With the help of several people on 3000-L I found my solution. Following is some information I got from a Response Center knowledge base article (DocID: KBRC00000601):

You can use NETTOOL.NET.SYS to see your routing list:

NETTOOL.NET.SYS

>>>NA

>>>RO

>>>RO

(your routing table will print on screen)

>>>QUIT

You can then use NMMGR to see what gateways you have configured and what reachable networks are on them and make the necessary adjustments.

If you make any changes in NMMGR make sure you press SAVE DATA and then go to the UTILITY screen and VALIDATE NETXPORT. You can then leave NMMGR and at the system prompt type:

:NETCONTROL NET=(your NI name);UPDATE=INTERNET