Binary patches: third party support today
November 6, 2007
HP made it very clear last week: Binary patches created for the HP 3000 are a common Hewlett-Packard repair for a 3000 bug. HP doesn't consider a binary patch any less reliable or more poorly engineered.
How interesting, then, to hear last week the comment from Allegro Consultants' Stan Sieler that his company, a Resource 3000 partner, could have produced a binary patch to fix the Large Files corruption problem. Sieler took note that Allegro could do so, but held back to wait on HP to produce a patch that could be tested more completely — and perhaps integrated more closely with the rest of the patches HP is developing for the MPE/iX environment.
HP had to reach down into the millicode that drives the move_fast_64 call in MPE/iX to repair the problem, for those of you who want to know every detail about the 3000's internals. The HP fix was better, Sieler noted, because it could be plugged into the rest of MPE/iX more easily. By HP, for now, and until the end of 2008. What happens beyond that date — even if HP creates more binary patches like this one — is a matter for OpenMPE to negotiate with HP.
HP worked quickly to find and patch the problems, and added a procedure that a customer can dynamically load to see if the current system has the patch. But Sieler noted in a message posted less than an hour after HP's announcement:
In this case we (Allegro) determined that we could independently produce a binary patch for the problem, but we realized that the community would be better off with an HP-provided patch, because it would fit in better with any subsequent HP patches.
In the future, that might not be the case ... source code access is critical to the ability for the community to develop patches!
That would be the source code access that OpenMPE has been campaigning and lobbying for with HP for the past three years. When using an HP 3000 is in your plans beyond 2008, source in any third party's hands will help an IT manager breathe easier.