Included software, tested job offers some disaster recovery

By Wirt Atmar

We have been using one of our HP 3000 Series 918s to shadow our primary development 918, using the MPE-to-MPE FTP capabilities of MPE. The purpose of doing this wasn’t to eliminate tape backups, but rather to ensure that if we lost one machine — and all of the recent backup tapes that tend to lie around it — we’d have another duplicate machine, completely ready to run at a moment’s notice in a completely separate building, far enough away where the possibility of both being destroyed by fire was highly unlikely.

Firstly, the job is extremely simple — and of course free. Indeed, there’s nothing complicated about any of it, nor are there any costs other than a few minutes’ time. The job is constructed as shown below, streaming itself to run at 3 AM every morning:

!job ftpxfer,user1.acct1,group1
!ftp 192.168.1.1
user user1.acct1,group1 psw,psw
prompt
mget *
quit
!set stdlist=delete
!eoj
!job ftpxfer,user2.acct2,group2
!ftp 192.168.1.1
user user2.acct2,group2 psw,psw
prompt
mget *
quit
!set stdlist=delete
!eoj
!job ftpxfer,user3.acct3,group3
!ftp 192.168.1.1
user user3.acct3,group3 psw,psw
prompt
mget *
quit
!set stdlist=delete
!eoj
!job ftpxfer,user4.acct4,group4
!ftp 192.168.1.1
user user4.acct4,group4 psw,psw
prompt
mget *
quit
!set stdlist=delete
!eoj
.
.
.
!job ftpxfer,manager.sys,manager
!pause 90
!stream ftpjob.manager.sys;at=03:00
!set stdlist=delete
!eoj

The primary development machine is running MPE/iX 5.5 PowerPatch 7, and the shadower running MPE/iX 5.5 PowerPatch 4. The primary machine has only 4Gb of disk; the shadower has 8Gb. There is a 10Mbit LAN between the two machines.

The backup of the primary machine onto a DDS-2 drive takes about 45 minutes to make a full CSLT/store copy of all files (approximately. 3.5Gb), using hardware compression, but there’s no need for us to transfer all of the user files from one machine to the other on a regular basis. The seven jobs represented in the jobfile above transfer only the regularly active development and corporate accounts and their databases. These seven jobs represent about 2.5Gb worth of material.

My initial experiments indicated that transfers across the LAN were just about as fast as DDS/compression on backups. That still seems to be true. A complete CSLT/store backup of the primary takes about 45 minutes; the transfer of about half that material across the LAN takes 23 minutes.

There is a caveat in that 23-minute number, however. That transfer rate occurs when we allow all seven FTP jobs to run in parallel. A 10Mbit LAN is the equivalent of six T1 lines. If the seven jobs all run in parallel, we seem to consume about 60 percent of the LAN’s bandwidth — leaving the equivalent of two T1s available for all other internal traffic, and that seems more than enough. While this intense internal traffic is flowing, normal terminal communications or Web page draws seem unaffected.

However, with all seven jobs running simultaneously, the disks on both machines are being exercised to their maximums, to the point that I consider it excessive wear on the disks. They’re really clattering. Thus, we now set the job limit to just one above the background jobs, so that the seven jobs execute in single file; however, doing this increases the transfer time from 23 minutes to 64 minutes.

A good portion of a single-file’s FTP bandwidth (dead-time) is consumed in just the negotiation between the two machines. Once the file transfer begins flowing, the data moves at a good speed. When all seven jobs are running simultaneously, whatever dead time on the LAN is left over by one job is filled in by one or several of the others. Nevertheless, the excess wear on the disks doesn’t seem worth the additional 40 minutes you save, especially at three o’clock in the morning.

I’ve tried multiple FTP syntaxes, but the one used in the job above seems by far to be the most certain. However, it only transfers MPE-named files, but that’s all we currently use, so it’s not a problem for us. IMAGE databases, KSAM files, and all “regular” files transfer with no problem. Symbolic links transfer, but seem to lose their “symbolicness” in the process. HFS files don’t transfer at all, using this syntax and the MPE version we’re currently on.

I’m also planning on upgrading both machines to 6.5. Once that’s done, we’ll be able to use Jeff Vance’s new Store-to-Disk option. If my understanding is correct, the great advantage of doing this is that we’ll be able to get all of the advantages of using the STORE command and assemble the store material into one file that can be FTPed between the two machines, and then RESTORED on the shadow.

However, I’ve never been particularly fond of partial backups, but in order to make the STD option work well, that’s what we’ll have to do. The FTP jobs above transfer every file in the specified groups and accounts, regardless of the recency of their modifications.

One final note: FTPing 2.5Gb of files between the two machines does not have the same impact on users as does a STORE-like backup does, where all of the files are marked for some time for exclusive access. Only one file at a time is locked as the MGET process walks through the file list. That attribute can obviously be either good or bad, depending on individual circumstances. Nonetheless, using the simple job that I’ve outlined above, that is the current behavior.

Overall, I’m quite tickled as to how it’s working. If we should lose the primary machine, we are (nearly) guaranteed of having a perfect replicate machine, available and ready to go, in building three.

State-of-the-art security is possible using tokens, agents and RSA secure servers with MPE/iX

By Andreas Schmidt

This article describes a way to build a security barrier around your HP e3000. It is based on material offered by Security Dynamics (www.rsasecurity.com), and on my own HP 3000 experiences in a project to roll out a Two-Factor Token Authentication to all platforms for a big company in the chemical industry, one which chose NT and HP 3000 systems as pilots.

Background

Today it’s a risk to trust only static passwords. Some studies have shown that approximately 60 percent of big companies have detected a security violation in the last two years, and more than 80 percent still use static passwords, especially to connect to the network. So it’s a good approach not only to rely on static MPE security, or third-party security solution passwords, but also to introduce a Two-Factor Token Authentication.

Two-Factor Token Authentication

Authentication is the process to verify the identity of users. On the Internet, cookies can provide automatic authentication for user names and passwords having been registered at a site, especially with SSL (Secure Socket Layer) encryption for things like credit card information.

On intranets, the authentication could happen with simple passwords, along with tokens or smart cards, or with biometrics that utilize the individual’s physical characteristics such as finger-print or retina.

Because passwords can become cracked or sniffed on the WAN/LAN, all methods using static authentication are not secure. The Two-Factor Authentication requires two factors before an user will gain access to a network or system:

• The person needs to have something: a token which produces a tokencode. Such a tokencode will change about every minute.

• The person has to know a PIN. This Personal Identification Number is unique and only valid for the physical token the person possess.

If an individual needs access to a server or a network component, they must log on to an Authentication Server or Agent and enter the PIN and the actual tokencode. As soon as the token has been recognized by the logon name and the Authentication Server has accepted the code combination, it cannot be used a second time. A sniffer has no chance to use the same combination of PIN plus tokencode.

The vendors of such authentication environments (server, agents, and tokens) ensure that each authentication token is unique and it is impossible to predict the value of a future tokencode by recording prior tokencodes. Thus when a correct tokencode is supplied, there is a high degree of certainty that the person is the valid user in possession of the physical authentication token and the remembered PIN.

One environment provider is RSA Security Dynamics, offering a SecurID Server, Agent, and Tokens.The heart is the RSA ACE/Server, the authentication engine on the network. It runs on different Unix flavors and Windows NT or 2000. This server is the management component of the RSA SecurID product family, used to verify authentication requests and to administer policies for enterprise networks.

All network components which should become authenticated must be defined on this server and become RSA ACE/Agents. When a person attempts to access a protected system, this software agent initiates an RSA ACE/Server authentication session instead of a basic password session. (This is true for Unix and NT, but not in this case for MPE, as we will see later.)

The user is required to enter the user name and instead of a static password, the current tokencode from the authentication device (the token) plus the PIN. The agent software hashes the information supplied by the user with additional data known only by the protected device (agent platform). It then transmits portions of the hashed information to the RSA ACE/Server, which approves access when the information is validated. The user is granted access, and this is logged onto the Server as well.

The last component is the physical device the user possesses, the authenticator or token. Many forms are offered. The one most used is a key fob: a device with a built-in chip and an LCD window to display the tokencode, small enough to be attached to a key ring. Others are credit card look-alike devices. The latest edition is software for palmtops generating the actual tokencode. Using any one of these devices, a person must possess them to authenticate, employing the same patented algorithm for encrypting and hashing the tokencode.

Authentication Advantages

Having installed such a system on all devices before access for an individual is granted, the security of a company’s network will be drastically improved. The four primary benefits are:

• Enterprise Authentication: Only those persons can access the devices when they are authorized to possess and use a token and PIN.

• Access Control: This is essential to protect against outsider attacks or malicious employees.

• Evasion of Attack: Hackers will try to unexpectedly gain access to a network. The Server identifies threat conditions, which are reported to the logs and alert the system manager.

• User Accountability: Damage may be done using an employee’s password without the knowledge of that employee. However, by logging the authentication process which requires PIN and tokencode, it provides more assurance of employee involvement in any unauthorized activities. The knowledge of this and of the comprehensive logging helps employees recognize their accountability for information security, so that their behavior is more secure.

The HP e3000 Agent Solution

The chemical company, which CSC is providing with IT services, decided to roll out Two-Factor Token Authentication over all platforms within one year. NT and MPE were selected as pilots: NT because of the large number of servers running that environment; and MPE because of the thinking that this platform might be different from all others and more difficult to implement. However, the company also recognized the importance of running its 3000-based Order Fulfillment Process with a lot of different outside partners.

RSA’s first attempt to develop an agent for MPE was very simple: A token had to become configured for a combination of MPE-USER-ID.MPE ACCOUNT. This combination could not be reused on another token. It was not possible to use wildcards or to add SESSION-IDs or MPE-GROUP to have a complete logon string. Because of the MPE characteristic to share logons (on all levels of capabilities) this version of the agent was not what we were looking for. (More drastically: This agent could not function for the MPE platform).

The second attempt was much better: everything was changed to the chemical company’s already-existing Security/3000 setup. Now Security/3000 invokes the RSA Agent to contact the RSA Server. It transmits either the SESSION-ID or the MPE-USER-ID as the name of the token. If the token is known and allowed to access the HP 3000, the agent asks the user for the current tokencode plus PIN.

This agent also functions without Security/3000 by adding some lines to the System’s Logon UDC. This drops some additional functions in combination with Security/3000, like verifying a user profile in any case (SESSION-ID,MPE-USER-ID.MPE-ACCOUNT is defined as allowed logon in Security/3000, all others will be refused before starting anything), but it will work.

One thing is essential: The RSA Agent for MPE does not replace the MPE password process like it does for Unix or NT! It is activated first when the HELLO string has been entered and the MPE password hurdle has been passed (Account, User, and/or Group Password) and (as an option) the basic check within Security/3000 for profile existence is passed. Now any other logon UDC functions are invoked, and this activates the RSA Agent.

Having Security/3000 in place is a good idea to replace the session passwords (if any) by supplying the tokencode.

Not having session names in place, the RSA Agent will add an additional password. I do not recommend eliminating the MPE password — it’s still a fence around your system and is needed for batch security (depending on the streaming security you have in place).

Having activated the RSA Agent, a logon sequence will look like Figure 1. The setup within Security/3000’s SECURCON.DATA.VESOFT file is shown in Figure 2.

Figure 1

SYSTEMA:hello paul,manager.sys
ENTER USER (MANAGER) PASSWORD: xxxxxxxxxxx

HP3000  Release: C.55.00   User Version: C.55.00   FRI, JUN  9, 2000,  7:34 PM
MPE/iX  HP31900 C.05.08  Copyright Hewlett-Packard 1987.  All rights reserved.
*************************************************************
                  This is a private computer facility.
      Access to it for any reason must be specifically authorized.
      Unauthorized access to this computer facility will expose you
      to criminal and/or civil proceedings.

      All information contained in this computer system,
      including messages, is the property of the company.
      The company reserves the right to access and disclose
      all information sent through or stored in this computer
      for any purpose.

************************************************************
               ********************************************
               You are at: Bad Homburg   SYSTEMA Series 960
               ********************************************

Enter PASSCODE:
PASSCODE Accepted
Welcome!  You are now signed on.
END OF PROGRAM
SYSTEMA: 

Figure 2

(* Setup for the RSA ACE SecurID Agent on HP3000    *)
(* =============================================    *)
(* Usersets if needed and wanted for later use      *)
$DEFINE-USERSET MPESEC &
            @[email protected]
(* SEC/3000 Session Names to identify individuals   *)
(* 1st line: all Online Logons                      *)
(* 2nd line: Accounts secured with MPE Methode      *)
(* 3rd line: general Exceptions                    *)
(* 4th line: AM user of MPE Methode (2nd Userset)   *)
$FORBID
"MPE('/var/ace/sdshell ![DWNS(HPJOBNAME)]') <> 0"
"SDI ACE Failed"
@.@&ONLINE-LDEV=20-LDEV=21-&
!MPESEC-&
@.TELESUP-SYSTEMB,XEALRMON.XFER-M,@.XFER-S,@.XFER
!MPESEC&ONLINE&CAP=AM

(* MPE UserIDs to identify individuals              *)
$FORBID
"MPE('/var/ace/sdshell ![DWNS(HPUSER)]') <> 0"
"SDI ACE Failed"
!MPESEC&ONLINE&CAP<>AM

(* Needed for both Methods                          *)
(* Exception Line: general Exceptions              *)
$FORBID
"IVAR(';SECURID',1) = 1"
"Invalid SecurID PASSCODE"
@.@&ONLINE-LDEV=20-LDEV=21-&
@.TELESUP-SYSTEMB,XEALRMON.XEXFER-M,@.XFER-S,@.XFER 

Here are our detailed notes on the Security/3000 configuration.

$DEFINE-USERSET: If in your current setup you identify individuals by their session name or their MPE-USER-ID, it’s a good idea to define a userset for later use.

$FORBID: in this section for all accounts, where the session name is used to identify an individual, the sessionname is downshifted (convention in defining the token on the ACE Server), and the program /var/ace/sdshell, the RSA MPE agent, is executed. If the program’s error code is not equal to 0 the logon is rejected. This will happen if the tokenname the ACE Server received is not allowed to get access to this HP 3000 Server, or is not known at all.

This $FORBID process must be executed for all sessions (but not for batch logons) except console and remote console. (If the network is down, the agent cannot authenticate with the ACE Server) The exception is for all accounts identifying the individual by the MPE-USER-ID, and some special accounts like TELESUP or EDI accounts (here:XFER).

The second userset within this $FORBID statement includes all Account Managers using the MPE-USER-ID as identifier. Here it’s assumed that individuals share one AM logon like MANAGER or MGR and are distinguishable by the SESSION-ID. The next $FORBID defines the same setup for accounts where the MPE-USER-ID is used to identify an individual. The MPE-USER-ID is used for the ACE Server Authentication process. This is needed for all session logons in these accounts except the AM logons.

The third $FORBID checks a variable named SECURID. The ACE Agent sets this variable. If the tokenname is known and allowed for this server, but the code transmitted is wrong (PIN and current tokencode for the token identified by !HPJOBNAME or !HPUSER), the logon is rejected with the error message “Invalid SecurID PASSCODE” (variable SECURID is 1). Otherwise, the logon is accepted (and logged as successful on the ACE Server like all unsuccessful attempts as well), and the individual gains access to the HP 3000. This check must take place for all sessions except those on the two consoles and the general exceptions.

This setup is proven and stable. Because of Security/3000’s flexibility, it’s almost possible to build up any other existing security concept, as long as the current setup already distinguishes between individuals. If this is not the case for any reason, it’s obvious that this must be changed first because of the characteristic of all authentication processes.

A similar setup is possible within a System’s Logon UDC if Security/3000 is not in place. It will become more complicated (some IF clauses, etc.) and will require more effort in changing the setup. But it is possible because of the simple logic of the ACE Agent and ACE Server:

Do I know the name of the token transmitted ?

NO: “SDI ACE failed.”

Is this token allowed for that network component ?

NO: “SDI ACE failed.”

YES: “Enter PASSCODE:”

Is the right PIN and tokencode transmitted ?

NO: “Invalid SecurID PASSCODE.”

YES: “PASSCODE accepted”

Access granted!

What if the ACE Server and/or the network is not available for any reason, so that no authentication could take place? In this case, a system manager must use the specific parameter to bypass the system’s logon UDCs and disable this authentication security. Because of this, it’s highly recommended to switch off the ENFORCE LOGON UDCS setup in SYSGEN (enforcelogonudcs OFF), but to have a hard-to-guess password on all MPE-USER-IDs with SM (only one, I hope).

Also, it’s obvious that in this case the only password remains the MPE-USER-ID password (and/or ACCOUNT password). It’s probably a good idea to prepare a new SECURCON.DATA.VESOFT configuration file in advance, which will be needed in this case.

For our chemical customer it’s not probable that this will happen: A second ACE server is in place with an automatic switchover if the first is not available, and the network topology is redundant. Nevertheless, for smaller companies this may become an issue. It’s not expected that RSA will port its ACE Server software to MPE to avoid such problems, if only MPE is in use.

Rollout to an HP e3000 platform

Assuming that your company wants to have such an authentication for MPE, it’s important to plan this in great detail. There are some dependencies which need to be observed.

Depending on whether you want to keep existing naming conventions to distinguish between individuals (a convention like six letters of surname plus first letter of first name) which is used for SESSION-IDs or MPE-USER IDs, or if you want to create a new one for naming the tokens (like randomized names out of a name generator), you need to make changes more or less within the HP 3000 security setup. Remember, such an authentication may be used on a company-wide level serving all platforms in place (Mainframe, Midrange, PC, Network components) and that one individual possesses only one token for all platforms. This token name is unique and usable on all platforms.

In any case, you’ll need a complete inventory of individuals accessing the HP 3000, including all their individual logons. This list could be created out of Security/3000 itself. It needs to be consolidated and expanded with the individual’s token name. If a new naming convention will be used, all MPE logon profiles (SESSION-ID,MPE-USER-ID.MPE-ACCOUNT) must be changed accordingly.

It may also be the case that the existing logon characteristics (!HPUSER, !HPJOBNAME) are used within application configuration and setup. In this case this must be changed in parallel. And first the Authentication Process on MPE system level itself must be activated.

Lastly, everybody will cry if they used automatic logon scripts: They no longer work! Whether such scripts were allowed in the past (containing passwords) depends on your setup. If so, you have to convince the users that this behavior was never secure. If not, you can be sure that nobody will continue to use such scripts — at least no longer to supply the tokencode (but probably the PIN, which is not recommended)!

You may work on an application-per-application basis, but this will negatively affect individuals who work in more that one application. (For example, in Application A the SecurID token is already needed, but in Application B it still uses the old method.)

Don’t underestimate this effort! It’s very easy to understand the process, but it is hard to roll this out in a living production environment, possibly serving many different user locations. It’s possible, but it needs a dedicated and experienced project management team to deal with all the different groups involved: techies, network people, security admin people, HR, the token vendor, application support, user help desks, user supervisors, end-users and more. People management may become more important than technology management!

Summary

Two-Factor Token Authentication is a state-of-the-art process to avoid static passwords. RSA Security Dynamics provides an MPE Agent for this purpose which worked perfectly for us with Security/3000, but also with basic MPE security. The technical approach is not simple, but manageable. The main problems may arise during the rollout because of human behavior in keeping known procedures and avoiding changes, especially for security. But to stay on HP 3000 into the future, the effort is worth it, especially for better security.

He saw nothing, nothing

From October, 2001

Just weeks before HP started to brief its vendor partners about the 3000 futures cut-off, customers asked about it. In a public forum of a webinar, the 3000's vendor relations manager, its product planning manager, as well as its customer spokesman said they knew nothing about the 3000 leaving HP's fold.

The questions surfaced in an October, 2001 broadcast. On November 14, the company released public statements. I was briefed on Nov. 9, and vendors leaked their notifications during the first week of November.

If nobody on that October Webinar knew about ending the 3000 business line, HP was certainly keeping its decision held as closely as a riverboat gambler's hand. Or perhaps a certain German sergeant on TV was the template for the answers.

After a few minutes of questions about support for disk mirroring, boot drives greater than 4Gb and other chestnuts often asked, HP began to address a number of questions about the impact of the merger on the 3000 product line. Customers asked about a published report in Network World magazine, wondering if the system was likely to survive the merger.

“I sure wish I knew the answer to that,” said Kriss Rant, CSY’s manager in charge of developer relations and a division veteran. “I don’t know any more than you do.”

“Whenever there’s a large merger like this, the press has a field day,” host Stachnik added, “speculating on exactly what it’s going to mean. I can tell you that nobody in the 3000 business has received any marching orders from Compaq or upper HP management that OpenVMS, MPE or any other operating system is supposed to survive or not. There’s been no decisions made on that. Don’t give too much credence to it.”

Platform Planning Manager Dave Snow noted that HP did a “total roll of our product line in February, and we’re delivering multiple processor support. I certainly think you can expect there will be support of MPE for many years to come.”

Other questions on the merger got a broad brush answer from Stachnik. “The correct answer at this point is, ‘We really don’t know,’ ” he said. “There are lots of open questions about whether that merger is even going to happen. The SEC needs to look at it, and there’s been all sorts of speculation in the press.

"How it’s going to impact the 3000 — we simply don’t know at this point. We’ve gotten no marching orders one way or the other, and I’m not anticipating we’re getting them anytime in the near future.”

From November, 2001

Recommendation includes five-year support guarantee, two more years of new sales

Hewlett-Packard proposed a new chapter for its oldest business computer on November 14, one that advises customers to transition away from the HP e3000 over the next five years. The announcement from 3000 division general manager Winston Prather and marketing director Christine Martino included news of a confirmed date for end of HP support and a halt of new sales in a little less than two years’ time.

HP said it will stop selling new systems on Oct. 31, 2003, ending its distribution of more than three decades of the most reliable business computer in the HP lineup. The company’s contract with North American distributor Client Systems - a company doing business exclusively in the HP 3000 line - has been extended for two more years. The computers will clearly be in service for quite awhile after that date, however, as HP is promising full customer support for the systems through the end of 2006.

“This really is about concluding that it’s time to advise customers of the long-term trend,” said Prather. “It has nothing to do with cost savings or downsizing. This is an advisory type of announcement.”

HP briefed the NewsWire several days in advance of the worldwide announcement to the general press. The announcement included news that HP will provide free unlimited HP-UX licenses for all customers who own the new A-Class and N-Class servers, and transform those systems into equivalent HP 9000 computers. And in the meantime, HP intends to continue selling the system, and upgrading it with projects that have already been announced. It will present papers and communicate with customers at Interex conferences during 2002, and continue its Webcast series with a January broadcast on transition.

“From a CSY perspective and a support perspective, it’s business as usual for the next two years,” Martino said. “It’s time for customers start their planning to move to a platform that will serve their businesses better in the future. HP recommends that customers begin transitioning off the HP 3000 to alternate HP platforms.” HP will be releasing an overview White Paper in the first of a series, “HP e3000 Migration Considerations,” from its Web site. More detailed white papers on transitions to HP-UX will be released in the future.

There’s even a silver lining in the announcement for some HP 3000 customers. The end of support date for MPE/iX 6.0 has been extended by six months to October, 2002, making it easier for companies using the HP 3000 9x7 systems to remain on the platform. HP stops support of that hardware in April, but software support for the systems has been extended as part of the transition. Series 939 and 959 system support has been extended to December of 2003.

The company is also notifying all of its customers on current support contracts by letter. Prather said the division started to brief its top-tier customers on November 9. “They were not surprised, and they really appreciated HP being able to tell them what we see as the future role of the platform,” he said. “At the same time they really love the platform, so there was some sadness in transitioning from the platform.” Prather said these top-tier customers “already have a multi-OS strategy, so they’ve been evolving their applications over time. It is a stake in the ground, but the CIOs I talked to were appreciative of hearing what the future holds.”

No layoffs or downsizing in the CSY division is being planned, nor are any additional technical development operations going to be shifted away from the California 3000 labs. The product has often been pointed to as a profitable part of the HP lineup, but CSY officials said profits didn’t enter into the decision to stop selling the systems two years from now.

The end of the CSY division seemed even fuzzier, despite its announcement of a date for the end of support. “When we get to the point where HP doesn’t need a CSY organization to support the 3000 customers, then we wouldn’t have a division,” Prather said. “We will staff the division to make sure we have whatever resources we need to meet our commitments, and we are committed through December, 2006. We will ensure from both a CSY perspective as well as our support organization and field support we have the staff we need.”

HP will also be helping continue the transition after the end of the support period. “After that, [CSY] employees will transfer to other businesses to continue the transition as well,” Prather said. HP hopes to capture HP 3000 business in its NetServer and HP-UX platforms, but recognizes that competitors will be targeting the customer base. “We will need to earn their business,” Prather said.

HP’s plans on database migration were less specific at the announcement. Prather mentioned HP Eloquence, a revision of the HP IMAGE database that’s been running on HP 9000 servers for more than a year, as an option for companies migrating their home-grown systems. Other customers should look to their application providers, Prather said, for advice and support on how to transition away from the platform. Martino and Prather said a “decline in the ecosystem” surrounding the 3000 prompted the move - and denied that the impending HP-Compaq merger had any effect on the decision to write HP’s last chapter in the 3000 community. CSY made the decision sometime after the last HP World conference, according to Prather. The general manager, who has spent his entire career managing technical and business advances for the platform, said he was saddened by his decision.

“I’m sad, because I’ve been involved in this forever,” he said. “But I feel confident we’re doing the right thing for customers. I can stand up in front of any customer and explain why we’re doing this,” Prather said. “It’s a recognition in general that we’re not going to be able to reverse the trends.” Martino said sales have been declining for the product, although the month of October, HP’s close of its fiscal year, was a record one in North America. She added that the division’s staff has been “going through stages of grief” over the decision. But despite CSY’s melancholy approach to the news, the division remains well in place trying to sell new 3000s to the community over the next 24 months. The immediate future holds no changes for companies relying on the system, HP said.

“We picked these dates that we’ll guarantee availability for customers, and we don’t have any plans to review those dates. We knew that the next question customers would ask is, ‘How long will this be a safe environment?’ That’s why we gave them these dates.” As proof of the safety, HP plans to continue with all of its announced enhancements for the system except moving it to the IA-64 platform. The ongoing PA-8700 project, which is delivering a chip that is expected improve performance another 30 percent over current top ends, will be delivered as promised. HP will also release new A-Class systems during the next two years, offering a performance bump for those low-end servers as well.

HP will also be releasing MPE/iX 7.5 next year, although the future releases of the operating system will be limited to Express updates beyond that, according to Prather. Native Fiber Channel will still be released, along with support for the new Ultrium tape systems and va7400 disk arrays. Possibilities of selling the business to another company and helping to create an Open Source movement to extend MPE’s life still may hold some potential for Prather. “We have a very diverse set of customers,” he said, “and in briefing our top-tier accounts, this doesn’t come up. I don’t believe doing any of that [Open Source] will change any of our recommendations for customers. I feel strongly that the ecosystem is starting to erode, and that right thing to do is move to another platform, hopefully an HP platform.”

But “having said all that, we will try to understand how we can help the evolution of MPE. If it is valuable to customers, we want to understand how we can help them.” Selling the source code for the operating system, as HP once did for the earlier generation of MPE, is also a possibility, “but I want to understand to who, and for what purpose.”

In the meantime, HP expects that a lively market is about to emerge around migration consulting and tools for the platform. “I have a feeling the third-party community will spring to life quickly to develop tools to help with the migration. I think a number of the partners in the ecosystem will look at this as an opportunity. This could bring the ecosystem to life for the transition period.”