HP responded to our Nov. 1 report with some corrections and clarifications about its new patches to avoid data corruption while sorting Large Files. In summary, the patches in question have passed beta testing and are now general released (GR), the sign that their quality satisfies HP's requirements.
What's more, HP recommends that customers install both the millicode repair patch as well as the patch to address issues with MPE/iX SORT processes. Craig Fairchild of HP wrote me this evening.
HP's strong advice is for customers to install both patches. You are correct in asserting a high priority for MPENX11, since it is the patch that addresses the issues with SORT and the MPE/iX OS. However, MILNX10 is also important to address the possibility of continuing to use the millicode in question. Even if a customer is not using Large Files today, there is no guarantee that they won't experience growth that will cause their files to cross into the large range at some later time.
What my initial report got wrong, according to Fairchild, was calling a binary patch testing status into question. Binary repairs like these cannot "skip steps," as I wrote in the Nov. 1 blog headline. If anything, HP says these critical patches got extra testing.
The first is the blog title, “Binary bug patches can skip steps”. This simply isn’t true.
There is a repeating of this theme throughout the article:
“...but the nature of the problem... might require more than binary patches.”
“these fixes will present a challenge to application developers who will need to integrate them into MPE/iX at some point.”
“HP didn’t do the usual testing for these repairs, it appears.”
“Binary patches like yesterday’s don’t have to cross the user testing and MPE/iX source code integration hurdles.”
The nature of HP's patches was called into question by Adager's Alfredo Rego and Paul Edwards of mpe-education.com — veterans of 30 years each in the 3000 community. I have one excuse that the words "general released" didn't come up in my interview notes, but I probably misunderstood what was said. I did have good notes from HP on "we've done as much testing as we can."
In a weak defense, it appears my confusion was shared by a couple of experts who were reading HP's very detailed report on the repairs. Edwards said, “There’s some strong issues here. I’m concerned that these binary patches were not done in the source code. So HP didn’t generate a General Release patch, which means it may or may not be tested on all three of the supported versions of MPE/iX. There was no beta patch, or anything.”
HP said the binary patch process is not new to the labs' development of bug fixes.
Patches MPENX11 and MILNX10 are General Released (GR) patches. These patches have undergone a more rigorous testing process than normal. Furthermore, HP has used binary patch technology when called for during the entire lifetime of MPE/iX. It has always been one of the patch technologies available and successfully used many times over the life of MPE/iX. There is no difference in quality between a General Release patch that includes binary components and those that don’t.
The abiding issue, according to the OpenMPE advocates, is that these binary component patches must be integrated into the MPE/iX source code. HP has announced no plans to do this kind of integration after December, 2008. OpenMPE wants to do this kind of integration, should HP give the group the green light to start working with the OS source code.