Great details of the problem and solution.
This is an example of another very good reason to get the MPE/iX software in
the hands of a 3rd party NOW, like OpenMPE. Because, after the end of 2008,
HP won't be able to provide these fixes. But, the 3rd party can. The time to
start the transition is before the end of THIS year, as promised by HP.
***************************************************************
CDR Paul Edwards USNR Ret. HP 3000 Certified Consultant
Paul Edwards & Associates
1506 Estates Way Phone: (972) 242-6660
Carrollton TX 75006 Cel : (214) 384-8728
Email: [log in to unmask] Web : www.peassoc.com
***************************************************************
-----Original Message-----
From: HP-3000 Systems Discussion [mailto:[log in to unmask]] On Behalf
Of F. Alfredo Rego
Sent: Wednesday, October 31, 2007 1:38 PM
To: [log in to unmask]
Subject: Re: [HP3000-L] HP Makes Critical Patches Available for Installation
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 *
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
