SIGIMAGE Newsletter Article

In a recent meeting of the SIGIMAGE Executive Committee (SIEC), it became clear that if a simple data dictionary capability were embedded into IMAGE, then some of our proposed ballot enhancements will have been solved and others will have much simpler solutions. To that end, the SIEC has spent some time recently debating the merits of this idea as well as discussing various implementation possibilities.

If this new enhancement makes it onto the ballot and subsequently receives a large number of votes, then we will be asking HP to implement a new facility into IMAGE. It is essential, therefore, that we think this out carefully. If we make this too complicated, there is little chance that it will ever be implemented. If we design it suboptimally, then we will not get all of the advantages out of it that we hope to achieve.

It is hoped that this article will get everyone thinking about this proposed enhancement, so that we can have a productive discussion over the SIGIMAGE e-mail reflector and during our next SIGIMAGE meeting on February 17 in Cupertino.

You can think of this enhancement as a way for IMAGE to store "extra" information about the database, the datasets, the items, and the individual fields. IMAGE stores information in the root file such as the number of datasets, the number of items, the dataset capacities, the item datatypes, etc. We are proposing that additional information be stored somewhere (more on "where" later) that can be retrieved later by applications and tools that might be interested in that information. Each piece of information would have a "tag" associated with it to identify what type of information it is, and would be associated with the database as a whole, an individual dataset, an individual item, or a specific instance of an item in a dataset (a field).

In deference to the location of the SIEC meeting in Las Cruces, New Mexico, we have chosen to call this the ENCHILADA enhancement, which of course, is an acronym for "ENhancement for caCHIng Limited Authorized DAta".

How might such a facility be used? Here are just a few of the entries from the SIGIMAGE enhancement ballot that would benefit from such a facility:

  1. DATE/TIME Data types. Rather than add new datatypes for the various date formats, a tag could be added that indicates which HPDATE date format is stored in that field. The data portion would contain something like "D23". Programs which wish to intelligently display some or all of the various date formats would request this tag to deal with the data appropriately.

  2. Z/Z+/P/P+ IMAGE/SQL problem. Whether or not a "P" or "Z" type field should be signed can also be stored in a tag. IMAGE/SQL could be made to use this data field.

  3. IMAGE/SQL split information. IMAGE/SQL splits are lost when a database is detached and reattached to a DBE. Split information could be stored in tags. IMAGE/SQL could then automatically use this information at database attach time.

  4. NULL Items/Default values. A tag could be used for handling items with NULL values. Either IMAGE itself could use the default value for fields not included in a DBPUT field list or perhaps an application program (or IMAGE/SQL) could use the value if a NULL ITEM is encountered.

  5. Tool "memory area". Tags could be defined for individual database tool vendors who wish to leave notes in a database, such as history, audit trails, work in progress, and checkpoint information.

  6. Tracking database files. Tags could be used to associate other files with a database, such as third-party indexing files, schemas, data dictionaries, or any other file that should be backed-up and restored along with the database itself. The data field would contain the POSIX name of the associated file. This tag would be useful to backup products.

  7. BLOBs. It was suggested that a tag could indicate that the field is a BLOB pointer, and could even indicate which type (MPE-file name, POSIX-file name, URL, etc.).

  8. COBOL picture. COBOL programmers have long wanted a place to associate a COBOL picture with a data item, to determine (among other things) where the implied decimal point belongs. Such information could be stored in a tag.

  9. Other IMAGE/SQL data. The entire process of attaching databases to IMAGE/SQL is a much-talked-about topic. Perhaps if additional information is stored as tags, then the process of detaching and reattaching can be made less painful.

  10. Broken chain information. When IMAGE encounters a serious error and is about to (maybe) create an I-file and (maybe) mark the root file as bad, perhaps it can add entries in a tag to help point database repairs tools at which dataset and record is not well, and what appears to be wrong. This could significantly reduce repair time on huge databases.

  11. Another tag could also be defined so that database administrators could add their own information to a database.

These are just the first potential uses that come to mind. I am sure that everyone can come up with several more. Perhaps the best use will come somewhere down the road. The nice thing about this feature is its extensibility.

As to the "where" question (Where should this additional information reside?), several options have already been suggested, each with their pros and cons:

The "Green Enchilada" proposal calls for a "hidden" master dataset with its corresponding B-tree index file. With this approach, access to the data would be accomplished through the standard IMAGE intrinsics (DBGET, DBPUT, etc.).

The "Red Enchilada" proposal would store this information in the root file, beyond the current EOF. Items would be written to this area through calls to DBCONTROL. Items would be retrieved through calls to DBINFO.

The "Enchilada de Caracol" proposal also uses DBCONTROL and DBINFO calls, but would store the information in a separate file, such as MYDBEX or mydb.000 for a root file by the name of MYDB.

Other flavors of Enchiladas have also been hinted at.

Please remember: We can think of all kinds of ways to complicate this and perhaps add to its potential uses. But, the more complicated we make it, the less likely that it will ever be implemented. The key here is to design a simple, extensible, backward compatible facility that can be used in the solution of several problems, not a panacea for the world's problems.

Please feel free to express your thoughts and suggestions on this subject. You may e-mail them to sigimage@interex.org, or use the contact information found elsewhere in this newsletter.

Updated 1999-01-12