IMAGE/SQL is an HP3000 MPE/iX software product which provides relational access (read, write, update and delete) to your TurboIMAGE data via the industry-standard Structured Query Language (SQL).

The teen-age product ALLBASE/SQL (“SQL”) and the mature product TurboIMAGE/XL (“IMAGE”) were joined together via SQL software and data structures to create the currently immature IMAGE/SQL.

In order for IMAGE/SQL to become a mature product, several things must occur:

DBSCHEMA Enhancement Request #1

IMAGE was released in the fall of 1974. In the intervening years, application developers who wanted to designate Packed Decimal (or other numeric) fields as sort fields were prohibited from doing so by an arbitrary constraint impose by DBSCHEMA. As a workaround, many developers defined the field (in the item table) as of type X or U but treated it as packed within their applications.

Of course there is “no free lunch”. The price for this deception was that the IMAGE documentation wasn't consistent with the actual data format and that query languages, such as HP's QUERY product, would not correctly handle the data of such fields. Currently, if such a database is attached to a DBE, the DBA must issue an UPDATE TYPE command in order for SQL to correctly handle such a mis-typed field.

These deficiencies can be eliminated by the simple expedient of removing the sort item type constraint from DBSCHEMA and re-defining the item to the correct data type (and length).

DBSCHEMA Enhancement Request #2

When an IMAGE database is attached to a DBE, SQL maps dataset names into table names and item names into column names. The only special characters allowed within the SQL names are “$”, “#”, “_” and “@”. Special characters allowed in IMAGE names but not in SQL names (“+”, “-”, “*”, “/”, “?”, “'” and “%”) are mapped into underscores.

In the long run, IMAGE/SQL will be easiest to maintain and use if the IMAGE names coincide with the SQL names. To assist developers in achieving seamlessness in names, I recommend that DBSCHEMA be modified to a) allow underscore characters within dataset and item names and b) issue a warning when an IMAGE name includes characters not permitted within SQL names.

However, I suggest that developers refrain from using the “@” character since it has a history of use as a “wild card” within the HP3000 community.

DBSCHEMA Enhancement Request #3

IMAGE permits data lengths up to and including 255 units (words, bytes or nibbles) for all of its data types.

Table 2-6 of the June 1993 edition of the HP IMAGE/SQL Administration Guide describes the data types and lengths supported by SQL. SQL supports all lengths of IMAGE data types X or U and supports R2 and R4 by converting them to and from E4s for computational needs at run time.

HP plans to revise Table 2-6 both for clarity and to reflect planned changes and additions including support for the IEEE reals E2 and E4.

I recommend that IMAGE database designers use only item lengths supported by SQL. HP can assist such developers by enhancing DBSCHEMA to issue a warning whenever a sub-item length exceeds the length supported by SQL for the item's data type.

Summary to Part 1

We at Adager are happy to see IMAGE finally accepted into the SQL world. Despite the fact that IMAGE was developed years before SQL, we believe that the interface between them (as provided by IMAGE/SQL) should be so seamless that it appears to be the result of a single project development.

With the cooperation of HP and 3rd party developers we can achieve that goal and thus make it a more desirable product to DBAs, developers and users.

Adager is already IMAGE/SQL aware and we will be more so as time goes on. In a future release Adager will permit you to apply the REDEFINE ITEM command to a sort item to change its item specs to correctly reflect the data format of the sort field whether HP responds to DBSCHEMA Enhancement Request #1 or not.