IMAGE/SQL: Part 4 of 5
Sun Valley, Idaho 83353-3000 U.S.A.
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 is a command which (like the ATTACH command and for the same reasons) should be available only to the DBC.
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, 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, 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.
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