IMAGE/SQL: Part 2 of 5
Fred White
Adager Corporation
Sun Valley, Idaho 83353-3000 U.S.A.
In Part 1, I recommended enhancements to DBSCHEMA which would assist development of SQL-supportive databases. Please include support for new data types corresponding to HP SQL types DATE, TIME, DATETIME and INTERVAL as enhancement #4.


In this part, I discuss global defects in the program called IMAGESQL.PUB.SYS (IMAGESQL) which make it difficult for Database Administrators (DBAs) to maintain their SQL DBEnvironments (DBEs) and their IMAGE/SQL databases (DBs). I could advocate a total redesign of the DBE data structures and the IMAGESQL command set but will not do so since I doubt that HP can/will invest in such a project at this time. Instead, I limit my recommendations to modifications which minimize the impact of these defects and make the DBA's job easier.
The primary metadata contained in a DBE fileset to support SQL access to a DB includes the dataset names, dataitem names and dataitem specs as they existed in the DB's root file at attach time. Secondary metadata includes an SQL-required OWNER name and manually entered mapping information which may be needed to override IMAGESQL's default mappings. Tertiary metadata includes tables of SQL-authorized users grouped by DBOPEN access class (password) and DBOPEN mode.
To create the primary metadata, the DB creator (DBC) performs three commands: SET SQLDBE, SET TURBODB and ATTACH. Secondary metadata, if needed (see table 2-6 of the HP IMAGE/SQL Administration Guide), is provided via the UPDATE TYPE and/or SPLIT commands. Tertiary metadata is provided by the ADD USER command.
To subsequently add/delete/change any of the primary elements (or access class PASSWORDs) the DBC must detach the DB from the DBE, make the changes and then perform the entire attachment process all over again.
To meet this need, during the initial attachment process IMAGESQL logs all of your commands to an EDITOR format file which, assuming you have saved it, can be used as an XEQ file in a subsequent re-attachment.
Due to flawed syntax, flawed functionality and flawed error handling, XEQ file re-attachments can completely fail or, perhaps worse yet, succeed (i.e., the ATTACH worked) but with erroneous or incomplete metadata left in the DBE.


Such “failures” arise from the following defects:

Suggested modifications

The following modifications to IMAGESQL will eliminate (or minimize the effects of) the correspondingly numbered defects described earlier:

To be continued ...

In Part 3, I will begin a review of all of the IMAGESQL commands. I will point out their defects and suggest improvements and/or workarounds.

What do your worldwide HP e3000 colleagues think of Adager? See a sample of comments from real people who use Adager in the real world, where performance and reliability really count.
Back to Adager