After a couple of dozen reports arrived, Sellitto, who had been firmly in the homesteading camp before her board of directors had their say, echoed the database importance:

The comments from the List reinforce my belief that it’s more about the database than the hardware or even the application software. Our IMAGE databases are so designed as to give great access times, except when we’re trying to look for a value imbeded within a non-indexed field.

Tony Summers of Smith & Williamson Corporate Finance Ltd. saw the database choice as a simple one. "You could take the opportunity to use migration to convert to a RDBMS  — and as some vendors have stated  — in a way that is transparent to the application. However, I would advise against this approach  — if you’re using IMAGE, then use Eloquence. If you’re using KSAM, use an ISAM file system."

Summers was also frank about the amount of integration that a long-time HP 3000 shop will have to shoulder when moving off of the platform:

The first step is to take a rain check on your current applications  — and look at how closely wedded they are to MPE and/or how much interaction they have with other servers. Do you use lots of JCL, or direct use of HP intrinsics in the application?  How easy would it be to replace your screen handling with a new layer?

Do not underestimate the steep learning curve you’ll need even once you’ve chosen what appears to be a suitable set of products and hardware/operating system. Keep reminding yourself that with the HP 3000 you usually had all layers of the application in one box and supplied by one vendor: user interface layer (VPlus) application (COBOL) and database layer (IMAGE/KSAM).

One seasoned 3000 professional after another recommended Eloquence as a solution for the 3000 shop that's been built around IMAGE. When Sellitto mentioned that the CFA is already using an SQL database on some Web projects, Lars Appel pointed out a specific Eloquence feature that might be useful to populate another database.

Your “subset” example somehow reminds me that, at least in some use cases, it might be feasible to “replicate” selected parts of an Eloquence database to another type of data store by using the “forward logging” and “auditing” features...

http://www.hp-Eloquence.com/support/B0710/doc/

The “forward logging” (somewhat similar to TurboIMAGE logging) captures database changes to logfiles, which can also be enabled for use in conjunction with the fwaudit utility, which in turn allows to extract (selected) subsets of the changes for review or further processing.

This could be used to populate/feed/update another database, SQL or whatever. Not a “real time replication”, but depending on the setup (eg frequency of logfile switches and extracts) something like once per day or once per hour sounds feasible.

OpenMPE board member Donna Garverick added that Eloquence puts familiar faces on the change to Unix or Windows. "I think for many MPE shops, the move to Eloquence makes a lot of sense," she said. "It mimimizes risk by letting the programming staff focus on actually getting the migration accomplished. Eloquence gives a wee bit of familiarity in a strange land."