Forwarded for Matt, who's having issues getting his answers posted:

For those in the community that haven't already voted, my responses 
to Ron's questions follow for your consideration. I thank you for 
your support in the past and ask for your continued support so I can 
continue to present your issues to HP for the benefit of the MPE/iX 
community.

1. HP has expanded its "permissible upgrade" language in its RTU 
licenses. Does the vendor need to offer anything to the community to 
prohibit the movement of MPE/iX from system to system? Something 
perhaps like unlocking the horsepower of the 3000s in the A and N 
Class?

OpenMPE has tried numerous times to get HP to consider unlocking the 
available CPU cycles on A and N class machines. The issue involves 
the third party software vendors licenses and sales on tier levels, 
and HP has stated they have no plans to unlock the extra CPU cycles 
because of third party software license concerns. I'd propose a way 
should be found that if a site can certify they have only x, y and z 
third party software and get a certificate from their software 
vendors, that HP allow the unlocking. After all there are sites that 
don't use any third party software that would have tier license 
issues, and these sites should be able to use their machines fully. 
It's questionable now if HP really could do anything to prevent the 
movement of MPE/iX to other machines, as they've not enforced their 
copyright literally hundreds to thousands of times, and any good 
lawyer is going to be able to beat them over the head with that issue 
and HP would stand a very good chance of loosing their case. In the 
case of copyrights, if you don't aggressively move to protect it, you 
loose it.

2. How soon must HP make a decision about its source code licensing 
for the 3000's operating environment? Is it acceptable for the vendor 
to wait until the start of 2010, as it plans to do now?

HP in the person of Ross McDonald has made public statements to the 
HP3000-L and the OpenMPE-L that HP will release responsibility for 
MPE/iX at some point in the future. I and others on the Board have 
been holding HP's feet (well, Ross' anyway) to the fire on this issue 
and that's one of the main reasons I'm running to remain on the Board 
- I want to continue to press Mr. McDonald to follow through with his 
(and HP's) commitments to release MPE/iX to an "outside of HP" 
company. Mr. McDonald may feel uncomfortable when I "put him on the 
witness stand and cross examine him" but sometimes that's necessary. 
As to 2010 - no, that is not acceptable. I've expressed to Mr. 
McDonald that the transfer needs to begin NOW, while HP still has the 
people in place that deal with the processes involved every day, and 
can pass on that knowledge in a business like and timely manner. I 
don't mean the technical ability to do the work, that already exists 
outside HP; I'm talking about the build and test processes that HP 
has created over the years that actually create a build or patch 
release.

3. What is the one achievement for OpenMPE which the group must 
accomplish during 2008 - the mission which the group must not fail at?

Getting the license issues for an emulator "in cement." This has 
progressed quite well up to this point, and I'm waiting to hear back 
from Jeff Bandle on a time for a joint meeting with all the 
interested vendors (U.S. based and Europe) to discuss license issues. 
Working with Birket Foster I've been leading the effort from the 
OpenMPE side to get the emulator into production, and that process 
has started. We've got a long way to go, but I definitely feel there 
will be at least one, and I'd prefer two, emulator products for the 
future.

4. Should third party support providers have access to HP's 
diagnostics, especially stable storage tools, in case of a system 
board failure, or the closing of a software company which cannot 
update licenses (with HPSUSAN numbers) any longer?

As others have said, there already exists third party software to 
address this issue. Prior to things like IRS and "Captain Greb" 
coming onto the scene, OpenMPE has had many discussions with HP 
regarding this extremely important issue. HP will not release 
ss_config for use outside HP, but HP has stated that their field 
engineers will be able to use ss_config with the guidance of the 
response center to service customers. HP has also stated the charges 
for this service is on a time and materials basis. Personally I'd 
like to see some way for HP to streamline this process to minimize 
the time it takes to recover a customer to production status when a 
cpu board swap is necessary. Perhaps one charge for 4 hour response 
time and another for 24 hour response. Presently it's only available 
(as I understand it) on a 24 hour response.

5. Should OpenMPE go after the mission of testing the dozens of beta 
test patches still stuck inside HP's 3000 labs? What can the group do 
to convince HP that the expertise is in place to do that testing, and 
release the HP improvements and engineering to the full 3000 
community?

OpenMPE has discussed this issue many times and offered to host the 
beta test patch distribution and result reporting process for HP. 
Paul Edwards has suggested that HP offer the beta patch test process 
to the DRPP community, and OpenMPE has the access to the machines 
necessary to perform this task and the expertise as well. OpenMPE has 
asked Mr. McDonald to consider having OpenMPE administer the beta 
patch test process as a "proof of track record" for OpenMPE, and it 
would help with the business relations between HP and OpenMPE as well.

Matthew Perdue
[log in to unmask]
Hill Country Technologies, Inc.
PO Box 460091
San Antonio TX 78246-0091
210-861-3000
210-579-1700 fax