Customers using TurboIMAGE on their HP 3000s will see many enhancements in the next six months. What they'll see beyond that is still being debated after extensive discussions at the IPROF SIGIMAGE meeting.
Jon Bale of HP's database lab updated attendees on projects they have asked about and heard about before: B-tree indexes (sometimes called ISAM indices); 32-bit ODBC support; third-party index composite index support; and index optimization for IMAGE/SQL. HP plans to have the B-trees available by the Express 3 release of MPE/iX 5.5, in or around HP World, as well as a delivery of the 32-bit ODBC package in that same release vehicle.
Gary Biggs, a member of the SIGIMAGE Executive Committee, reported on his early tests of B-trees. He said the software he'd tested delivered 600 to 800 percent better performance at the expense of modest disk space increases. The software is limited to 16 indices/chain heads per detail dataset and can only index IMAGE key values in master datasets, not composites or keywords.
"I've got Quiz reports that run in a fraction of the time it took under regular TurboIMAGE," Biggs said. He added that B-trees appear to be well matched for datasets requiring a lot of updating.
Biggs did note one significant downside in his tests: a 25 percent slowdown when third-party indexing and B-trees were used together in a database. HP was aware of the performance hit in the mixed environment.
Marking time on IMAGE dates
Bale, who manages the HP database R&D lab and heads up the HP
Solution Team
for database enhancements, said HP's date and time project for IMAGE needs
input from
customers before HP can determine if it's feasible. Bale said the project
has an impact on
many HP software solutions, from fundamentals like Query to the esoteric
such as
Business Basic.
"There are major implications if we do date and time datatypes in IMAGE on a number of products from SSD, such as Query, Transact and so on," Bale said. "We're looking at a system-wide solution that has large implications. We are trying to get some ideas about the level of support that you think would be reasonable for some of these products if you want us to implement this enhancement at all."
Debate over the basic architecture of date/time datatypes sprang up not long after Bale's introduction. One set of customers believes a single datatype, closely aligned with Microsoft's representation for dates and time in SQL, will be the best solution for compatibility. A larger group of customers said that multiple datatypes will cover all possible needs better. Bale said the project is "under investigation." Some customers are keen to employ an HP solution in this area while they do the Year 2000 work on their applications in the coming year.
HP engineers didn't leave IPROF with a clear message about which design was the predominant choice of the customers. Coupled with Bale's need to gather data on which HP applications need to support the datatypes, delivery of a solution could be months away. "What we are looking for is some kind of requirement," Bale said, adding about the scope of a date/time solution: "The more we are asked to do, the less likely we are to do it."
IMAGE/SQL redesign
The date datatypes emerged as the leading candidate for IMAGE
enhancement
once Bale and others at the meeting began to dismiss the top two requests:
direct access
through ODBC for TurboIMAGE and KSAM/MPE files without Allbase overhead. The
continued emergence of third-party solutions for this convinced Bale that
HP could
spend its resources in better ways than duplicating functionality already
for sale.
The wait for any HP solution to Allbase-free ODBC might make it meaningless once it arrives, said SIGIMAGE chair Ken Sletten. "The people who need this, need it now," he said.
While a serious part of the meeting revolved around comparison of the forthcoming ODBCLink/SE driver with HP's current middleware, some customers still maintained that the long-awaited HP solution still won't make IMAGE/SQL any easier to use.
"I disagree strongly that the ODBC stuff is going to fix all the problems with IMAGE/SQL," said Chris Hagood, implementation manager for Health Systems International (HSI), Pueblo, Colo.
Hagood had sharp criticism on the level of IMAGE/SQL's stability and functionality before the meeting. Only a last-minute HP patch for the software resolved problems he encountered with IMAGE/SQL being unable to do some selects and a LEFT OUTER JOIN correctly. He also has complained about the Allbase optimizer being "rudimentary at best" in handling TurboIMAGE data. Hagood wants to replicate his TurboIMAGE databases for use with Oracle databases. He is using Allbase/SQL for the moment because he sees it as his only option.
The operations at HSI, a fairly large site with six HP 3000s and three HP 9000s, using Oracle's gateway to get at their IMAGE data on the 3000 through IMAGE/SQL. Hagood said HSI has had no problem overwhelming the IMAGE/SQL Transaction Manager (XM). Overflowing the XM buffer can stall transactions, because the buffer's limits aren't dynamic. It's a problem that doesn't effect sites that don't do a high volume of transactions through IMAGE/SQL. HP is reportedly investigating the issue, according to Horizontal Growth solution team manager Larry Boyd.
In the meantime, HP heard the same criticism it has heard in the past about the ability to administer production-grade IMAGE/SQL operations. "I get the feeling that IMAGE/SQL was entered into step by step, without any overall design," said Fred White, who created the original IMAGE with Bale. "It's a database administrative nightmare and an annoying learning curve. We're asking you to do it all over again."
MDX designs discussed
The SIGIMAGE discussions touched only briefly on the dynamic
Master dataset
expansion (MDX) feature that's already in design at HP. Some database
experts think
that MDX, as it's being built today, is ripe for customer abuse and is an
accident waiting
to happen. While HP's Bale has been heard to say that he doesn't recommend
customers
use MDX, once it's delivered it will be hard to keep it out of the hands of
managers
whose operational load is growing rapidly.
MDX is supposed to eliminate the need for around-the-clock sites to bring down systems for master capacity changes. In much the same way that the capacities of dynamic detail datasets (DDX) are automatically increased once a threshold is reached, MDX will give the masters more capacity when they are 80 or 90 percent full.
There's some debate over whether 80 or 90 percent is the most appropriate figure. Many capacity checking utilities already check for an 80 percent threshold.
The ability to increase master dataset capacities automatically in this way could lead to performance problems, according to Adager's Ken Paul. Lengthening synonym chains is a byproduct of making a master dataset dynamic, causing a gradual decrease in system performance. Only rehashing can resolve this kind of slowdown, a lengthy operation in itself. Rehashing requires a capacity increase, a painful operation for the downtime it requires.
One possible resolution is to make it possible to repack the overflow area of the master dataset, which is structurally similar to a detail dataset. But 24 x 7 sites don't have the downtime available to repack detail datasets, either. HP would have to deliver the capability to repack while databases are online.
BLOBs in IMAGE
Support for Binary Large Objects (BLOBs) in IMAGE ran right below
date/time
datatypes in the SIGIMAGE request list this year. Used with multimedia-type
files and data
such as scanned checks, BLOBs are becoming more important to enterprise-grade
databases. Customers at IPROF suggested that HP implement the enhancement
through
some kind of pointer mechanism, to keep the data out of IMAGE but give the
database an
easy way to access it.
Such a BLOB index could be an object manager, according to Wirt Atmar of AICS Research.
"The structure of IMAGE in this design would be more like the index that appears at the end of a textbook," Atmar said in a recent Internet posting. "The index is the IMAGE database. The pages of the book are orthogonal BLOBs. If you wished to read every page in the book that had something to do with subject X, you would search the index as you always had and then retrieve only those pages of interest."
Like the customers at the IPROF meeting, Atmar believes BLOBs themselves don't belong inside IMAGE. "The advantages of this form of design is that IMAGE remains small and compact, thus easily backed up, and very fast in retrieval -- while the BLOBs are free to evolve as necessary, almost without impact on the fundamental nature of IMAGE or the CPU that bears it."
Like the MDX and date/time datatype issues, the BLOB discussion at IPROF gave HP more input on what will be required to bring these enhancements to market.