At 5:20 PM +0000 10/31/07, Fairchild, Craig D wrote:

>We would like to advise you of a set of situations that Hewlett-Packard has identified with MPE/iX software which, in very rare circumstances, could lead to data corruption on HP e3000 systems running MPE/iX Releases 6.5, 7.0, and 7.5. Hewlett-Packard has software patches for these releases ready to correct these situations, MPENX11 and MILNX10, available at the HP ITRC (http://itrc.hp.com/) or via your HP Support Representative.  Though Hewlett-Packard believes very few, if any, customers are at risk, HP strongly recommends that all customers take the following corrective actions:
>
>*       Install MPENX11 and MILNX10 at your earliest possible convenience (see the patch descriptions below)
>*       Your non-HP applications may be impacted: examine the applications running on your systems to determine if they meet the criteria to require a recompile (see the notes on patch MILNX10 below) For those interested in more technical details further information is available on the JAZZ web server: http://jazz.external.hp.com/milli
>
>Patch MPENX11 addresses the following issues with MPE/iX:
>1) SORT.PUB.SYS and programmatic calls to HPSORTOUTPUT: Customers on MPE/iX Release 6.5, 7.0 or 7.5 who sort 4GB or more of data are at risk. When either interface is used to sort more than 4 GB of data, the returned record length could in rare instances be corrupted. If the record length returned is less than it should be then data could be lost.
>
>2) MPE/iX OS millicode handling of long pointer access to large files: When the OS copies data from a long pointer location only one byte from a range is moved if, and only if that range starts six, five, four, three or two bytes from the end of a four gigabyte space and the length of the move transfers all remaining bytes of the space. No other source address or transfer length combinations are affected nor are transfers to such addresses.
>
>Patch MILNX10 addresses potential issues with non-HP Software:
>It is possible for non-HP Software to have an issue similar to the MPE/iX OS millicode issue described above and thus be at risk of corrupting data.  Addressing this issue may require that non-HP Software be recompiled after installation of MILNX10.
>
>Recompilation is not required for programs reading data exclusively through MPE/iX File System intrinsics like FREAD, FREADDIR or HP compiler library file access routines such as C/iX read(), Pascal/iX read(), COBOL READ, as long as patch MPENX11is installed.  A recompile may be required if customers and ISVs have written code to read data from files larger than four gigabytes using Large Mapped pointers, AND used move_fast or code statements that result in a call to $$lr_unk_unk_long or $$lr_na_unk_long.  Then, as in the OS issue above, if data is moved starting at locations six or fewer bytes from the end of a four gigabyte boundary, millicode could silently move less than the requested amount of data.  HP recommends that customers and ISVs rebuild any applications which read data from large files via long pointers to include the new version of the $$lr_unk_unk_long and $$lr_na_unk_long routines via the new MILLI.LIB.SYS delivered in MILNX10.


First of all, I would like to congratulate our HP vCSY friends for their fast response to these critical issues. 

Second of all (nothing new ;-) it appears that HP continues its policy of not acknowledging any of the help it has obtained from its hard-working partners.  That's OK, because I have reason to believe that this is forced upon our vCSY friends by HP's corporate legal department.  Boy, how I miss the days when I used to walk the floors of HP's buildings while chatting with Bill Hewlett and Dave Packard in the early 1970s.

But I digress.  I wonder how many people will actually understand the problems as described by Craig's (very technical) posting.  I am under strict CDA rules with HP, so I am very limited in what I can say, but I hope the following will not unleash HP lawyers on me.

The Adager team described the problem with move_fast_64 to HP on August 8, 2007, after we discovered that the first HPSORT patch not only did not solve the problem but introduced a new one by using move_fast_64.

Craig implies that only non-HP applications might be affected.  What about HP applications?  I believe that the "move_fast_64" procedure is used extensively by HP within MPE/iX.  Has HP taken care of all the possible problems within MPE/iX?

Adager calls HPSORT programmatically.  We detected, analyzed, documented, and reported the initial problems to HP during tests on our own hp3000 systems as well as on some large customers' systems.

The problems encountered by Adager customers were not caused by Adager code, but by HP's code.  Once the "latest" HPSORT patch was applied, the problems went away.  The patch ID we tested is MPENX06, which is different from the patches mentioned by Craig.  It seems that patch MPENX11 includes the fix for HPSORT.

Craig does not mention that the problem can exist while using simple calls using FREADDIR on files with bug-exposing characteristics.  He does provide a nice technical description under the section on "MPE/iX OS millicode handling of long pointer access to large files."

It's not clear (to me, at least) whether the patches identified by Craig are already available as General Release or still in beta.  We have not received either one of them, even though we generated the original bug report.  Is HP confident that the problem has been completely resolved without any user testing?

Adager users are safe.  Even when they may experience the problems that Adager exposes when calling HPSORT without the patch, Adager will leave the databases unchanged after reporting the problem.

Under any circumstances, I would like to express my appreciation to HP's vCSY team for the great effort (and the tremendous speed) that they put into these issues.


Back to my programming cave, which feels a lot cozier than the ruthless corporate legalese-infested jungles out there,

  _______________
 |               |
 |               |
 |            r  |  Alfredo                  http://www.adager.com                     
 |          e    |                            
 |        g      |  F. Alfredo Rego                   
 |      a        |  Manager, R & D Labs           
 |    d          |  Adager Corporation
 |  A            |  Sun Valley, Idaho 83353-3000            U.S.A.
 |               |
 |_______________|

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *