Database Webcast maps IMAGE replacement

HP explores performance shortfalls, SQL differences

Like commuters tuned to rush-hour traffic reports, HP’s customers and partners had already heard about the slowdowns ahead while driving toward non-IMAGE databases on alternative platforms. HP used its fifth Webcast on migration issues to convince those database drivers that the tie-ups in Oracle intersections weren’t that bad.

HP’s Bill Bennett explained that the design of some programs that were built for IMAGE/SQL’s efficiency could be a poor match for SELECT-based database alternatives such as Oracle. Migrating applications which use chained reads, for example, onto Oracle could result in slower response. Driving techniques are very different in the non-IMAGE world.

“It’s inefficient programming methodology, and takes more resources,” he said. Using a SELECT statement that yields the entire chain, “you still have to do the additional checks to make sure that the records are what you’re looking for. What you’ve done is now double your work. The SELECT could have done all that work for you in one pass. You’ve now just got part of what the select can do, and you now have to do more programmatic work.”

Lee Tsai of iMaxsoft, the HP 3000 database utility company formerly known as LeeTech, said programs migrated directly from IMAGE to Oracle would be 20 to 30 percent slower on HP 9000s. Using a lot of JOINs “or any fancy queries will slow them down significantly,” he explained, stretching the slowdown to 50 percent.

Good database structure without long chains can mitigate the performance penalty, he added. Using embedded SQL as if it were calls to TurboIMAGE intrinsics is “a bad thing,” according to HP’s Webcast host George Stachnik. New programmers will look at such embedded calls — a style that worked fine for IMAGE/SQL designs — “and wonder why you didn’t just do the work in your SELECT statements,” Bennett said.

Database zoned numeric items from IMAGE don’t exist in Oracle or SQL Server, so they must be translated. Conversely, IMAGE has no date datatypes, so the data in numeric fields being used as dates in IMAGE databases must be checked before they are converted to SQL’s date datatypes.

“Date types are one of the most complex issues,” HP’s Bennett said. He explained that using non-date characters, such as a string of 9s, in date fields is commonplace among HP 3000 customers’ applications. Replacing those 9s with a valid date could mean the item now has a completed-by date. “Some people call that sloppy programming, but it’s something that’s often been done in TurboIMAGE,” Bennett said. “If you want to take advantage of the SQL date types, you also have to understand if you’re being very consistent in the use of the date fields in the IMAGE database, and not trying to get more out of them than just the date.”

IMAGE, on the other hand, has array data items, something that doesn’t exist in SQL databases such as Oracle. Speedware’s Product Marketing Manager Nick Fortin suggested that customers migrating data could replicate the concept of such arrays with SQL’s columns and tables.

Fabricating one big column, separated logically as array elements, is one way to replicate IMAGE’s arrays. Another method is to replicate one column within the same table that there would be an array for — “in other words, the corresponding dataset goes into a table in the target database, and to have one column per array element,” Fortin said. “This creates a lot more flexibility into the database design, because you can add more occurances; it’s just a column to add to the table.”

HP’s Stachnik said that it was clear “in an hour’s Webcast we won’t be able to hit all the issues” around database migration. MB Foster Associates’ George Marcinek said one hidden issue is that applications have been designed for the 3000 with implicit knowledge of the data. Database fields designed for one kind of item get used for something completely different. Such issues have to be resolved if a customer wants to replace an existing application’s use of IMAGE with Oracle, for example.

New migration tools

To help guide migrating customers through such snarls, several companies made brief mention of new tools to ease database movement into Oracle or SQL. Transoft talked about a Transoft Database Access Module (TDAM) is a wrapper technology which emulates the IMAGE intrinsics. TDAM maps the database access performed by these intrinsics into access to Oracle and SQL Server relational databases on the Unix, Linux or NT platforms.

Tsai of iMaxsoft mentioned this his firm’s Open Turbo helps move IMAGE databases to Oracle on HP-UX systems. The company’s Open Turbo Emulator allows the 3000 applications to access Oracle locally, or access Oracle remotely from the 3000s. Open Turbo has a set of database objects for Oracle under Unix “that will ensure any future Oracle application may coexist with a migrated application.”

Transoft also provides a way to replace 3000 applications with all COBOL and embedded SQL. “We create what we call IO Modules, which is not like taking embedded SQL and plugging it into the code,” said Transoft’s Mike Dixon. “It’s like having a data access module, where the calls are going into the IO modules instead of going into the data access module. The embedded SQL is all COBOL, and completely supportable by your COBOL staff with basic SQL knowledge.

Wrappers make the problems of database migration “less worrisome,” said iMaxsoft’s Tsai, “because you don’t change any data access routines. You use the same DBOPEN, DBPUT and DBFIND, and don’t change those calls to SQL statements.”

Transoft has an internally-developed tool it calls a Schema Parser, which looks at existing IMAGE schemas and creates all the SQL required to move the data into Oracle or SQL Server. Data types and naming standards are automatically taken care of, “if you’re doing no redesign, making your database as it existed in IMAGE,” said Dixon.

These wrapper-style emulators should allow 3000 applications to access SQL databases on other platforms, to be able to compare differences between data in the local IMAGE database and the new Oracle database. Alignment issues, packed decimal issues, and byte order issues will also differ from one COBOL compiler to another. So wrappers should allow applications migrated onto HP-UX to access IMAGE/SQL databases on the 3000, to ensure the application has been properly migrated.