We work in a business with its eyes on the future. For some, there's nothing as important as what's next -- preparing for it, scheduling what's coming up. Development begets anticipation, too. If you create software, you try to visualize a future with your project completed.
The downside to this forecasting is that we savor our well-planned tomorrows at the expense of our todays. Living in the present is a luxury that many of you don't afford yourselves. Instead you live in the poverty of the uncompleted project, because of the undelivered feature or the unavailable tool.
It can be much more simple. Anything you wait for more than a year might not turn out to be what you want anyway. And any tool holdup you're weathering in client-server middleware bears some closer scrutiny.
Tool availability can be a sore subject in the HP 3000 world. One of the longest-standing needs is for database connectivity to TurboIMAGE, specifically through Microsoft's Open Database Connectivity (ODBC). More than a year ago, developers using HP 3000s asked Hewlett-Packard to include ODBC connectivity in the operating system as soon as HP could deliver. True, they already had ODBC middleware to serve the world of Windows 3.1 client tools -- things like Visual Basic and PowerBuilder. Microsoft's sweeping splash of Windows 95 was another matter, however. The 32-bit world that Win95 created didn't have an HP-supplied path between HP 3000 databases and those slick, graphical interfaces on PC desktops.
More than a year later, it still doesn't. Third parties that have stepped in to sell what HP is still working to bundle. Companies using ODBCLink from M.B. Foster Associates praise the product and the connectivity it brings. So much praise rained down that HP decided it should buy what it was slow to build. A deal was signed between HP and M.B. Foster. ODBCLink got a trimmed down cousin, ODBCLink/SE, to be shipped with a future version of MPE/iX.
Trouble is, it's too far in the future for some. Those 3000 developers living in tomorrow can't make their forecasts and plans a reality. It will be some months before anyone can use ODBCLink SE. Total time elapsed between those first customer requests to HP and delivery could be 18 months. That's the same as never for customers who need to develop something today.
They have options, of course. Some are contacting M.B. Foster to evaluate the full version of ODBCLink. That's probably a good idea, considering what the SE version leaves out -- access to KSAM, Powerhouse dictionary and MPE files, the ability to establish serial links, links to detail datasets, and most important, ODBC access without stepping into the snarl of Allbase/SQL.
All that might have been included in the SE version, but HP would have spent a lot more licensing the product from M.B. Foster. ODBCLink/SE solves connectivity problems, but it still demands you wrestle with Allbase/SQL to maintain your attached databases. HP didn't want a new way to link TurboIMAGE to SQL. It wanted only the 32-bit capability of ODBCLink, lashed to the past of the Allbase/SQL.
This development effort has been proceeding with all possible speed at M.B. Foster's labs. They are to be commended for seeing a business opportunity that could solve part of the 3000 community's client server connectivity needs. Still, some developers are pretty sore about the delay. They see it as a sign that HP doesn't care about the 3000 anymore.
I think the delay shows HP cares more than ever.
No, my brain's not fried from the never-ending Texas summers. I am thinking simple, however. You're being spared an IMAGE ODBC option that requires Allbase/SQL. That's too complicated for client-server development on the HP 3000.
That might be your only option, if it weren't for Java. I think HP's doing customers a favor by keeping that new ODBC solution out of circulation until late spring. By that time, Java development tools, new middleware and security enhancements could be moving along nicely. Java is simpler.
ODBC, a standard proposed by Microsoft, is designed to keep you in lock-step with the gods in Redmond. And those gods' keep engineers informed with information from the top down. Microsoft proposes, and you dispose. Even HP struggles to get timely and accurate information about Microsoft's latest ODBC "Jet Engine" specifications, then understand how they impact HP databases. How anybody with less clout than HP can do as well is a mystery to me. M.B. Foster has, but their model is sound: very few programmers in a close-knit team. An HP 3000 guru told me the ideal development group is "two programmers yelling across a partition."
Not all ODBC development is so well structured. And then there's the problem of overhead. ODBC adds a lot, by most accounts. Frankly, we don't see a great adoption in the 3000 customer base on client-server as it has been defined up to now, via ODBC. Sure, it's on everybody's to-do list. That's because for the last two years the concept has flowed from the lips of every consultant and the pen of every magazine editor. By now those sages are learning, from the early adopters, that ODBC client-server is more expensive and complex than they first believed. Half the projects get abandoned. Those that complete do so at about 180 percent of budget, on average.
Java is simple, if still a little immature. A vast community of developers and publishers and software houses is forming up under the Java banner. More than 200,000 are involved, by one count. Why such a fast pickup for a technology only announced a year ago? It's a simple design for client server that costs less.
Sure, there's safety in sticking with the leader and using ODBC. But so far its track record has projects dying half the time and running well past budget most of the time. That's the downside to simplifying by sticking with the biggest player. That player's vision of the future is a lot like the present, only bigger.
If you're a developer whose visions demand a 32-bit ODBC for MPE/iX immediately, don't blame HP for not shipping ODBCLink/SE soon enough. And you can be glad you'll be spared the complexity of administering TurboIMAGE attached databases through the snarl of HP's required Allbase/SQL component.
If you've got to wait, hold out for a simpler future. HP's riding the Java wave like many other systems vendors and big IS shops. Maybe the Internet doesn't have much to offer your HP 3000 shop. But the technology that drives it, used as inside-your-company intranets, offers a lot you can use right away. A little Java here, a free browser there, and some middleware to bring IMAGE data to the browser, and you've got a client-server solution that's manageable. That Java middleware might surface before HP's ODBCLink/SE ships. We'd watch Minisoft for that development.
If your eye is fixed on the future, look for an open standard. Open your horizons to something just as elegant as MPE/iX in its design. Keep your client-server development simple, like the HP 3000.
-- Ron Seybold