AdagerHome Your Adager Guide (Section 4 of 13)
First | Prev Table of Contents | Index Next | Last


IMAGE/SQL databases and Adager
For convenience, we use "IMAGE" to mean also "IMAGE/SQL," "IMAGE/3000" and "TurboIMAGE."

There are differences among the various flavors of IMAGE, but they have to do with limits and interfaces, not with substance.

Adager keeps track (and enforces the requirements) of the various incarnations of IMAGE and their operating-system and hardware environments.


Databases as repositories for your information
An IMAGE database models the dynamic behavior of entities (or resources) and their relationships by means of data entries.

IMAGE uses datasets to consolidate homogeneous collections of entries.

Application programs may access a database's entries by means of IMAGE intrinsics (dbget, dbput, dbupdate, dbdelete, and so on) or by means of SQL statements (select, insert, update, delete, and so on).

An entry consists of a key (which uniquely identifies an entity, resource, or relationship) and a collection of attributes (which give quality and color to the entity, resource, or relationship). IMAGE uses fields to define keys and attributes.

A data item defines the name, the security and the format of all fields with the same name. For instance, if you have a field called "status" in the customer dataset, a field called "status" in the product dataset, a field called "status" in the employee dataset, and so on, you only need to define one global data item called status. When you specify "status" as a field in various datasets, all of the global properties of the data item get inherited by the field instances. When you change a data item with Adager, the change gets propagated to all of its associated fields.

Adager allows you to adapt and to manage all kinds of IMAGE objects as well as the data structures that support them.


Security
Image has security mechanisms that allow you to regulate access to a whole IMAGE/SQL database, or to specific datasets within a database, or to specific fields within a dataset.

You can limit such access to read-only capabilities, if you wish to preclude some users or processes from modifying your database's information.

Adager allows you to adapt and to manage all of these IMAGE security features.


Access to your information
IMAGE uses two kinds of datasets: masters and details.

A path is a performance booster that allows quick access to entries with related search-field values.

A chain is a group of data entries with the same search-field value (according to a given path's search field). Each chain in a path consists of a master entry and all detail entries (if any) whose search-field values equal that of the master entry.

Adager allows you to adapt and to manage all of the IMAGE hashing and chaining objects: synonym chains, detail chains, paths, search fields, sort fields, primary paths, and so on.


Global database flags
If you allow a database to run in production with AutoDefer enabled and with transaction logging disabled, you risk destroying your IMAGE/SQL database in the event of a system interruption.

Adager monitors the AutoDefer flag as well as other global database flags on your behalf and sets them according to a strict set of rules designed to maximize your database's availability and recoverability. For instance, Adager always disables, automatically, the AutoDefer flag if the logging flag is not set.

Adager always tells you the current status of the flags and the new settings it recommends for them. At any point after having used Adager, you can always assign any value you wish to these global database flags by means of DBUTIL.


Jumbo datasets (larger than 4 gigabytes)
Adager supports jumbo datasets (with more than 4 gigabytes).

Adager's approach is transparent to you and there is nothing special for you to do to manage jumbo datasets. Adager takes care of all the technical details on your behalf.

Adager automatically handles the transition for existing non-jumbo datasets that "jump" into the jumbo realm by virtue of a larger capacity or field layout (and for jumbo datasets that "jump back" into non-jumbo by virtue of a smaller capacity or field layout).

Adager's preprocess consistency checking tells you, up-front, whether a database has a jumbo dataset or not.

Adager's reporting functions tell you, dataset-by-dataset, whether a specific dataset is jumbo or not. Report schema, for instance, includes comments (on the dataset capacity line) regarding the dataset's jumbo status.

When you change the capacity of an existing dataset, Adager (besides reporting the dataset's current capacity specifications) displays its current jumbo status.

How fast is Adager when dealing with jumbo datasets? For detail datasets going from non-Jumbo to Jumbo (or vice versa), Adager uses a very fast in-place technology.

For jumbo master datasets, Adager's performance is similar to its performance for non-jumbo master datasets.


Dynamic Dataset Expansion (DDX for details and MDX for masters)
Dynamic Dataset Expansion (DX in general, DDX for details, and MDX for masters) allows automatic expansion of the capacity of a dataset (master or detail) as soon as DBPUT reaches the dataset's current limit. You specify the maximum dynamic capacity that you want to allow for each dataset.

Adager makes sure that your version of MPE/iX and IMAGE supports the particular kind of Dynamic Dataset Expansion—master or detail—that you request:

If you don't have the appropriate version of MPE/iX and IMAGE, Adager will not allow you to enable DX and will give you a warning if it detects, for example, that you have restored a DX-enabled database into an older system whose MPE and/or IMAGE versions are not up to DX standard.


SQL DBEnvironments
For IMAGE databases that are attached to SQL DBEnvironments, Adager automatically maintains the synchrony of the interrelated data structures.


Indexing (B-Trees and TPI)
IMAGE provides its own internal indexed-sequential capabilities by means of B-Trees. Third-Party Indexing (TPI) provides, in addition, keyword retrieval capabilities to IMAGE.

Adager supports both kinds of IMAGE indexing structures (Image's internal B-Trees and TPI).

You need IMAGE version C.07.04 (or newer) for IMAGE B-Trees. Adager preserves (and rebuilds, if necessary) B-Tree indexes as it performs database transformations. Use DBUTIL to add B-Tree indexes to your masters. 

:run dbutil.pub.sys

HP30391C.07.04 TurboIMAGE/XL:  DBUTIL (C) COPYRIGHT HEWLETT-PACKARD COMPANY 1987

>>help addindex

       ADDI[ndex] database name[/maint word]
          FOR <ALL | setnamelist | setnumlist>

>>help dropindex

       DROPI[ndex] database name[/maint word]
          FOR <ALL | setnamelist | setnumlist>

>>help rebuildindex

       REBUILDI[ndex] database name[/maint word]
          FOR <ALL | setnamelist | setnumlist>

>>exit

END OF PROGRAM

NetBase (and SharePlex) database mirroring
Adager communicates with NetBase (and SharePlex, HP's OEM version of NetBase) to automatically replicate any and all Adager changes on the mirrored database.

NetBase mirrors simple changes (such as capacity increases) as well as complex structural changes (such as adding or deleting paths or fields).

Please see your NetBase (or SharePlex) documentation for details.


Further information
There is a wealth of published material on technical and managerial aspects of IMAGE databases.

The members of the Adager Lab have contributed a significant amount to the literature and will be happy to steer you in the right direction if you have specific questions.

An excellent starting points is Adager's web site:

http://www.adager.com

Join HPe3000-L (mailing list) and comp.sys.hp.mpe (newsgroup) for discussions with your worldwide HP e3000 colleagues. To search HPe3000-L archives or to post, subscribe, unsubscribe and change your subscription options:

http://raven.utc.edu/archives/hp3000-l.html



AdagerHome Your Adager Guide (Section 4 of 13)
First | Prev Table of Contents | Index Next | Last