More IMAGESQL.PUB.SYS Command Flaws

Subsequent to Part 3's discussion of the defects in the IMAGESQL.PUB.SYS (IMAGESQL) commands “SET SQLDBE”, “SET TURBODB”, “ATTACH” and “ADD USER” as implemented under ALLBASE/SQL version A.G0.24, I discovered that the ADD USER command is rejected if the SQL database environment (DBE) is “in use” (i.e., an SQL process is “connected” to the DBE). This forces the TurboIMAGE database creator (DBC) to use ISQL to “stop” the DBE prior to performing any maintenance of the SQL user tables associated with his/her TurboIMAGE database (DB).

Since “stopping” a DBE terminates SQL access to all DBs attached to the DBE, this is yet another reason for IMAGESQL to support “wildcards” and MPE group names within the user name portion of the ADD USER command. As described last month, this would allow the DBC to add and/or delete SQL users externally to IMAGESQL (and without having to “stop” the DBE) simply by using existing MPE commands.

I also discovered that the ATTACH command is unsuccessful if the DB is the first DB to be attached to the DBE and the DBE is “in use”. Until this defect is removed, the DBC must also “stop” the DBE prior to performing the ATTACH.

This month, I review the IMAGESQL commands “DETACH”, “DELETE USER”, “UPDATE USER”, “LOG ON” and “LOG OFF” as implemented under ALLBASE/SQL version A.G0.24.

DETACH

“DETACH” is a command which (like the “ATTACH” command and for the same reasons) should be available only to the DBC.

DELETE USER

Like the “ADD USER” command, the “DELETE USER” and “UPDATE USER” commands are rejected if the DBE is “in use”. Here again, the DBC is forced to “stop” the DBE in order to maintain the SQL user tables of the DB.

Of course, if and when HP supports “wildcards” and MPE group names within the ADD USER command, this same capability must be provided within the DELETE USER and UPDATE USER commands.

UPDATE USER

“UPDATE USER”, in common with ADD USER, currently requires the use of IMAGE access class passwords. UPDATE USER should be modified to allow the DBC to specify the user's access class with a “CLASS=<integer>” part.

This is preferable to using the “PASS=<password>” method of specifying the user's access class because a) it permits the DBC to modify access class passwords within the DB without obsoleting existing ATCLOG files for use as XEQ files and b) the record logged to the ATCLOG file wouldn't contain a password and thus constitute a security risk and c) there would be no need to warn the DBC about the logging of an access class password and d) the DBC wouldn't need to enter as many characters to identify the access class.

(The use of passwords should be phased out. “PASS=” parts within ADD USER and UPDATE USER commands should be replaced with “CLASS=” parts within the corresponding ATCLOG records.)

LOG ON
and
LOG OFF

“LOG ON” and “LOG OFF”, are used by the DBC to turn IMAGESQL logging ON or OFF, respectively.

The HP IMAGE/SQL Administration Guide states that “When logging is on, all commands entered are logged to the ATCLOG file.” It would have been better if it read “When logging is on, all syntactically valid IMAGESQL commands except for LOG ON and LOG OFF (and, possibly, all DISPLAY commands) which are successfully processed are logged to the ATCLOG file.” providing, of course, that is how IMAGESQL logging is actually performed.

The current version of IMAGESQL logs all responses (including MPE commands, carriage returns and whatever) to an ATCLOG file (which can be file equated) and does so prior to processing the response. If the user saves the ATCLOG file for use as an XEQ file in a subsequent re-attachment process (as suggested by HP) and if the re-attachment process is run as a job, the job will terminate upon encountering any log record which causes it to return an error message.

Even if the logging facility is improved to exclude the logging of “garbage” responses, its command processing facility must be enhanced to distinguish between critical and non-critical “errors”. If this is done, then in job mode it would terminate only if a critical error occurs, such as a failed SET TURBODB or SET SQLDBE command.

To be continued ...

In Part 5, I will critique IMAGESQL's automatic and manual mapping facilities.