This has absolutely got to be a record: 1778 postings to HP3000-L during the 28-day period September 25 through October 22. I think that 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 HP3000-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 of information this month was the origin of the name of the 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.

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

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

"I was provided the following information from my HP Acct 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:

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

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

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.

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

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

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

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

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.

This comes up often enough, I thought I should include here a recent series of postings from HP3000-L that tie several things together:

Q: Is there anything in this message I can use to determine what is being miss-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.

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

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

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

I had the same problem not long ago. If you convert the PARM= from hex to dec 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 HP3000-L I found my solution. Following is some information I got from a 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

This will update the network settings without the need for rebooting or even stopping the network.