NewsWire FlashPaper

3000 NewsWire FlashPaper, October 1997

News so hot it might ignite

Express 3 is delayed, but not significantly

HP started putting the word out in mid-September that it wouldn't be shipping MPE/iX 5.5 Express 3 by the end of September. The release is being delayed until the end of October at the latest, and might be available as soon as you read this issue of the NewsWire. Details were sketchy about the reason for the delay, as always when HP slips a delivery date for software, but Kriss Rant of CSY talked about more testing being required. With every feature that HP adds to MPE/iX, it increases the amount of coordination between patches and tests it must perform -- all of HP's applications and utilities must be tested against new features, and there's a lot in Express 3 that needs to be merged up against the many patches that are a regular part of any modern operating system release. The delay will only impact those customers who've been waiting a long time for things like ODBCLink/SE. Most customers will get the release and wait until the upcoming year-end holidays to install it, anyway. Is it possible that CSY understands this behavior, and will roll out most of your MPE/iX improvements well after your kids have gone back to school? Well, we look over the last 12 months and find it to be true, with 5.5 going out in late October last year and only minor Express 1 and 2 updates shipping at any other time. Autumn is HP 3000 update season.

HP's ODBC driver isn't the only IMAGE/SQL solution impacted by the delay

While the customers' wait for ODBCLink/SE climbs into its 14th month with the Express 3 delay, another HP 3000 solution for IMAGE/SQL connectivity was also waiting on the release to start spreading its connectivity message. We're talking about Linkway, the 16- and 32-bit ODBC solution from CSL Solutions in the UK. The two products are related in more than one way this month. They both require IMAGE/SQL for their connectivity, and we can't hear from CSL Solutions yet about the specific advantages of Linkway over ODBCLink/SE until the HP software ships. That's because CSL Solutions is a beta test site for ODBCLink/SE as part of its charter as an HP Client-Server Integrator. We won't be drawing any conclusions without some TestDrives of these solutions, but if you're wondering how someone could sell ODBC connectivity that relies on IMAGE/SQL when HP is giving it away, think about feature sets and complexity of queries. HP has admitted it is bundling a limited ODBC solution in Express 3. How limited will depend on whether you want to do calculations as part of your lookups and whether you need access to things like MPE and KSAM files. (Look for our TestDrives of Linkway and ODBCLink/SE in upcoming issues of the 3000 NewsWire.)

Tivoli and Unison are on a single path, but Roadrunner's track is unclear

Unison Software, makers of the MPE/iX backup solution Roadrunner who went public two years ago, agreed to be acquired by IBM networking subsidiary Tivoli in a $170 million stock swap. But Roadrunner is far from the focus of the deal. Tivoli officials said they were after Unison's Maestro as part of the deal, needing a robust scheduler with multiple platform support to beef up the Tivoli TME 10 enterprise management suite. The two companies were allies before the merger -- because Unison was one of the charter members of the TME 10 vendor partner group -- and Unison already sold a module that can integrate Maestro with TME 10. Tivoli wants to simplify control over application functions spanning mainframe and client-server systems for all TME 10 users and believes Maestro is just the tool to do that.

That's good news for TME 10 customers and of some interest to HP 3000 Maestro sites, but there's been nothing said about the fate of Roadrunner as a result of the merger. Unison Software -- the company -- may cease to exist after the merger is approved by shareholders. Tivoli has never offered backup solutions. It's also a little questionable whether a company owned by IBM -- that's Tivoli -- would put any effort into a solution that's almost exclusively sold to support computers that compete directly against IBM systems. Even though the product hasn't had much of an update recently, Roadrunner customers are a satisfied bunch, according to a quick check we did a few months ago when ORBiT International offered a competitive upgrade to Backup/iX. We wonder if that ORBiT offer will get renewed in the face of a change in ownership to Roadrunner.

That to-do list in the IMAGE labs gets no shorter

The long-awaited b-trees will be out soon, and 32-bit ODBC support will be available any day now. So why is it that Adager's IMAGE support expert Ken Paul isn't satisfied? Well, the member of the SIGIMAGE Executive Committee sees an urgent need for date/time datatypes in the favorite database for HP 3000 developers, and there still hasn't been any word on when, or even if, the data types will be available to customers. A passionate discussion about the missing date element in TurboIMAGE and IMAGE/SQL was a highlight of the SIGIMAGE discussion at the IPROF forum in March. Since then absolutely nothing has been revealed to the SIG's members on the data type, which might have helped Year 2000 projects if it had been ready before 1998.

That looks unlikely now, especially since there's still debate over whether IMAGE should do any date checking at all. Customers have been successful with IMAGE for over 20 years without an official date datatype by creating their own, although those were 20 years without the shadow of a millennium change looming overhead. As Paul says, "It would be a very big change for IMAGE to actually have a data type whose contents are enforced by the IMAGE. Even though you define a field as being a U10, you don't have to have uppercase information in it. IMAGE has never cared." Paul went on to note that a technical call from the M.B. Foster Associates organization helped reveal to him "that DBLOCK is the only intrinsic that was coded to do type checking of arguments versus field type."

Paul believes the most critical to-do item for the labs is one of "a major need to address the current [IMAGE] limitation issue. This will probably be my crusade for the next several years." The biggest HP 3000 customers are encountering real limits in databases, and the IMAGE lab, Paul believes, "will probably will do a small fix by making the block pointer an unsigned number instead of a signed number which will double the true limit of an IMAGE dataset . But [Adager colleague] Fred White and I would like to see IMAGE convert all pointers to 32-bit or even 64-bit numbers and get it over with. This would require a similar program like DBCONVert, which would also make it difficult to move databases from one machine on a new version of IMAGE to a machine on an older version of IMAGE. But we feel that the Lab will have to bite the bullet sooner or later."

Luckily for those big customers, that kind of work doesn't have to happen exclusively in HP's labs anymore. The forthcoming master dataset expansion (MDX) project is being coded and tested outside of HP with oversight from the HP database lab. If resources are scarce inside the labs, at least there's a good alternative. There's plenty to do: those stalls of the Transaction Manager still don't have an official fix, according to Executive Committee member Chris Hagood. And while all the advances of the last few years are great, the customer base is always asking for more. You'd think there were thousands of companies out there using this database to keep their businesses alive or something. You don't hear this kind of complaining from the HP 3000 Oracle community, no sir. They have their own issues to wrestle with in the dark, like performance...

Why Oracle won't ever run slower than IMAGE on paper

On paper might be the only place it doesn't. The latest version of the best-marketed database for the HP 3000 is set to go out to customers on total support this month, making life a little better for the companies who need to use Oracle on MPE/iX. That version is sure to include the same magic clause in the contract that keeps a fair comparison of database speeds between IMAGE/SQL and Oracle from ever happening, at least with any attribution. Probably penned by Oracle's marketing department, the clause reads that "Customer shall not... disclose results of any benchmark tests of Programs to any third party without Oracle's prior written approval."

It's curious wording, considering how often measurements of speed appear in Oracle's advertising -- when Oracle is the winner. That clause, and why it's there, might be something to consider this month as HP's latest Oracle sale prices for the 3000 wind down. Those lower costs are important if your management says you gotta use Oracle to match your other non-3000 platforms. But the savings could be offset by the cost of a faster 3000.

Make Java fast enough to use

We've been as impatient as anybody to hear about Java production success stories on the HP 3000. While there is a high hype factor surrounding the language, it looks like performance issues with the product might be one of the things holding up customers' willingness to deploy it on MPE/iX systems. There are pilots in development, but no mission-critical apps to gawk at yet. HP recently announced a new JIT compiler for Java, but now it also appears that a simple change from the Posix command line might do as much as any new Java compiler can to speed up the cross-platform language running on MPE/iX.

Mike Yawn, the HP engineer who's led the Java/iX porting effort, recently reported that Java's "classes.zip file that is being distributed is not a byte stream file, but is in fact a variable length binary file. This results in a dramatic performance problem when loading classes from the file." Yawn went on to say that "the problem is that when a Posix program like Java accesses a variable length MPE file, the system has to jump through a lot of hoops to emulate a byte stream file. One of the things that happens is that when you seek to a position in the file, MPE has to read all of the intervening data so it can figure out where to pretend that linefeed record delimiters exist." There's a simple fix. Converting the classes.zip file into a true byte stream file appears to immediately speed up Java on the 3000 by as much as 3-6 times for simple operations like compiling and executing a "Hello World!" type program. Yawn said you can do this on your system by logging on to MANAGER.SYS, getting into the Posix shell and issuing these four commands.

$ cd /usr/local/java/latest/lib
$ mv classes.zip classes.zip.old
$ tobyte ./classes.zip.old classes.zip
$ chmod 444 classes.zip

Of course, if performance isn't what's holding you back from Java/iX -- and you're waiting for it to be a supported product that's included in the MPE FOS tape -- it might be a good idea to let HP know that's how you feel. We don't know of a lot of people doing much more than experimenting with shareware, but you might be the exception. Send your comments about HP fully supporting Java/iX to Yawn at mike_yawn@hp.com. After all, HP is supporting Samba/iX as of the 6.0 release of MPE/iX.


Copyright 1997, The 3000 NewsWire. All rights reserved.