HP 3000 Manuals HP 3000 Manuals
TurboIMAGE/XL Enhancement Details
by RJ Diepeveen
Commercial Systems Division
With this version of MPE/iX, TurboIMAGE/XL offers some new and exciting
enhancements. Critical Item Update and Indexing should be of particular
interest to many of you. Hewlett-Packard is pleased to make all of these
enhancements available to you in this release.
The new TurboIMAGE/XL enhancements in this release are:
Critical Item Update
Indexing using Third Party Interface
Dynamic Rollback for Remote Database Access
IEEE Floating Point Real Numbers
Four (4) Gigabyte Dataset Sizing
This article provides general information about the operation and some of
the uses for the new enhancements. The information presented here is in
no way intended to serve as a complete guide to the use of these
enhancements. The new TurboIMAGE/XL Reference Manual (30391- 90001,
fourth edition) provides you with greater detail.
CRITICAL ITEM UPDATE
In all previous versions of TurboIMAGE/XL (and IMAGE/3000 as well),
DBUPDATE was limited to the modification of non-critical items. By way
of definition, critical items are KEY items that are found in Master
sets, and search and sort items that are found in Detail sets. DBUPDATE
can now modify search and sort items.
Intrinsic Call Sequencing
If your application required a critical item to be modified, it was
necessary to completely delete the existing entry and then add the entry
back with the modified critical item. The intrinsic calling sequence,
using a COBOL example, would look like this:
CALL "DBGET" USING DBNAME, SET, MODE, STATUS, LIST, BUFFER, ARGUMENT.
CALL "DBPUT" USING DBNAME, SET, MODE, STATUS, LIST, BUFFER.
CALL "DBDELETE" USING DBNAME, SET, MODE, STATUS.
In most cases, the DBPUT is done first to insure that the call can
complete, then the DBDELETE is executed to remove the initial entry. The
disadvantages to this calling sequence are that linkage updates are
occurring on all paths, and the new entry is added to the end of chain on
all paths (unless a chain is sorted) destroying entry chronology on the
chain.
By using the CRITICAL ITEM UPDATE feature the calling sequence is
simplified to this:
CALL "DBGET" USING DBNAME, SET, MODE, STATUS, LIST, BUFFER, ARGUMENT.
CALL "DBUPDATE" USING DBNAME, SET, MODE, STATUS, LIST, BUFFER.
The contents of the buffer in the call to DBUPDATE would include the
modified search or sort item. The linkage changes occur only for the
affected paths, not all paths. Chronology on unmodified paths is
preserved. The amount of work done by DBUPDATE is significantly less
than that done by the DBPUT/DBDELETE calling sequence thereby providing
improved performance in comparative situations.
CIUPDATE Settings
By default Critical Item Update is DISALLOWED for a database. This is
done to preserve backward compatibility for existing software
applications. To take advantage of this enhancement the Critical Item
Update feature must be SET using DBUTIL. Within DBUTIL you must first
issue the following command:
>>SET basename[/maintword] CIUPDATE = [DISALLOWED ]
[ALLOWED ]
[ON ]
DISALLOWED prevents any process from using Critical Item Update on this
database (Default).
ALLOWED indicates that programmatic enabling of the feature is possible
through calls to DBCONTROL mode 5, but programs that do not make this
call are prevented from using Critical Item Update on this database.
ON allows any process to update critical items in this database unless
the process explicitly disables the feature by calling DBCONTROL mode 6.
This option allows Critical Item Update to be disabled in selected
programs while enabling it for the majority.
The DBUTIL command SHOW, with options ALL or CIUPDATE, displays one of
the following settings:
CIUPDATE is DISALLOWED
or CIUPDATE is ALLOWED
or CIUPDATE is ON
Programmatic Control
When the CIUPDATE setting is ON or ALLOWED then the DBCONTROL intrinsic
can be used to affect the manner in which a process, using a specific
DBOPEN access path, can use DBUPDATE. DBCONTROL mode 5 allows critical
items to be updated for the baseid used in the DBCONTROL call. DBCONTROL
mode 6 prevents critical items from being updated for the ^fsbaseid used
in the call to DBCONTROL.
There are other modes that can be used with DBCONTROL, and details about
all of these are available in the reference manual.
DBINFO Information
The DBINFO intrinsic can be called with mode 502 to obtain database and
access path information about Critical Item Update. DBINFO mode 502
returns two 16 bit halfwords containing the database setting and the
current setting for the ^fsbaseid used in the DBINFO call. The possible
return values are:
Halfword 1 contains the DBUTIL CIUPDATE setting:
0 = Critical Item Update is DISALLOWED (default)
1 = Critical Item Update is ALLOWED
2 = Critical Item Update is ON
Halfword 2 contains the current setting for this DBOPEN access path:
0 = Critical Item Update is disabled for this accessor
1 = Critical Item Update is enabled for this accessor
This table shows defaults and options:
Halfword 1 Halfword 2 Default Halfword 2 Options
0 0 none
1 0 0,1
2 1 0,1
DBCONTROL modes 5 and 6 affect the value in halfword 2.
New CIUPDATE Error Messages
With new features come new error messages, and CIUPDATE is no exception.
Error conditions vary with the ability of a process to modify critical
items. If CIUPDATE is not allowed for the baseid, for whatever reason,
and DBUPDATE attempts to modify a critical item, then the standard
condition 41 is returned with the following message:
DBUPDATE attempted to modify value of critical item--key, search or sort
This error is always returned if a DBUPDATE is attempted against a KEY
item (located in a Master set).
With CIUPDATE enabled, whether at the database level or at the baseid
level, the following error conditions are possible, each returning a 41
in halfword 1 of the status array, with differentiating values in
halfword 3 of the status array:
Status
Element 3 Message
1xx No chain head for (master entry) for path xx
2xx Full chain for path xx (contains 2,147,483,647 entries)
3xx Full automatic master for path xx
4xx Full automatic master synonym chain for path xx
Another message you may encounter relates to the use of DBCONTROL mode 5
to activate your use of a ^fsbaseid access path for CIUPDATE. If the
database CIUPDATE setting is DISALLOWED, then DBCONTROL mode 5 returns
condition -82:
CIUPDATE is set to DISALLOWED; cannot use critical item update
There are additional messages within DBUTIL related to setting and
displaying the CIUPDATE options and are primarily informational in
nature. Please refer to the TurboIMAGE/XL Reference Manual (30391-90001,
fourth edition) for details.
Design Considerations
Modification of critical items has been disallowed for so many years that
with its implementation come caveats and usage considerations. Before
using this feature testing should be done to understand the ramifications
of its use. Here are some considerations to keep in mind in the use of
this enhancement:
* DBERROR and DBEXPLAIN interprets the entire status array and
presents the new error messages.
* Applications may depend on DBUPDATE returning a condition 41 when
modification attempts are made to critical items. Additional
checking must be done by the program in these cases.
* When a search item is updated, the entry is no longer found on the
chain of the previous item value and is at the end of chain for
the new item value (unless the chain is sorted).
* When a sort item is changed, the entry logically moves within the
chain to the new position. TurboIMAGE/XL allows sort items of
data types X, U, and K, corresponding with ASCII, upper case
ASCII, and absolute binary values. Values are sorted in ascending
order. Should the new sort value be greater than the old value, a
subsequent chained read (DBGET mode 5) encounters the entry again.
If a backward chained read (DBGET mode 6) is employed and the new
sort value is less than the previous, the entry is seen again.
* DBOPEN modes 1, 3, and 4 support Critical Item Update. Mode 2 is
not supported as this feature requires locking or write exclusive
capabilities and DBOPEN mode 2 allows shared DBUPDATEs, but does
not enforce locking.
Updating of critical items has a been a request for some time, and we
hope that with this implementation of the feature your applications will
enjoy new functionality. As indicated by these considerations, some
aspects of the feature need to be carefully thought out. Please refer to
the TurboIMAGE/XL Reference Manual (30391-90001) for complete details of
CIUPDATE.
INDEXING WITH THE THIRD PARTY INTERFACE
Another very popular enhancement request has been for TurboIMAGE/XL to
perform Generic Key searches. This functionality would mean that a
partial key value could be used for searching, and returning entries
would contain key values where the partial value was all or part of the
item. For example, suppose your item name was COMPANY, and you wished to
find all entries where the COMPANY value began with the letters HE.
Qualifying entries might include HEATING SPECIALISTS, HENRYS DRY
CLEANING, and HEWLETT-PACKARD CO. This is just an example of generic
value search capabilities.
Several software suppliers have produced quality products that fill this
very niche, plus add a multitude of other sophisticated search
methodologies. Hewlett-Packard has contracted with two of these
suppliers to provide their solution to TurboIMAGE/XL users using a
supported interface operating with external standards.
The two products are OMNIDEX, from Dynamic Information Systems
Corporation (DISC) of Boulder, Colorado, and SUPERDEX from Bradmark
Technologies, Inc. of Houston, Texas. Each product provides Generic and
Keyword Retrieval methodologies, each having options that include
Wildcards, Boolean and Relational Operations.
The integration of TurboIMAGE/XL with these third party products is
seamless and offers these products an umbrella of protection for data
recoverability and logical integrity.
NOTE This enhancement requires a magnitude of documentation that exceeds
the scope of this article. The highlights are presented here;
however, additional details are best obtained from the
^fsTurboIMAGE/XL Reference Manual and the software suppliers
themselves, DISC and Bradmark.
External Changes
Many of the TurboIMAGE/XL intrinsics have been enhanced in the
implementation of TPI (Third Party Indexing). In addition, root file
information has been added to allow proper control and manipulation of
TPI structures by TurboIMAGE/XL utilities.
As each intrinsic is addressed, note that an increase in the number of
supported modes is the common theme. This allows full backward
compatibility and extension into the new functionality that TPI offers.
Nearly all the intrinsics now include a range of modes reserved for TPI
functions beyond the standardized functions.
The most significant external changes appear with the search and
retrieval intrinsics, DBFIND and DBGET. DBFIND now supports multiple
modes, making possible the various standard, generic, and keyword search
methods now available. DBGET has also been given new modes, again to
deliver the entries qualified by the expanded DBFIND capabilities.
DBOPEN and DBCLOSE now support a larger number of modes, mainly to
accommodate third party functions beyond the standardized functions.
DBPUT, DBDELETE, and DBUPDATE still operate fundamentally the same;
however, all indexing functions are completed as part of the intrinsic
call.
DBINFO now supports an 8xx range of modes that report on a variety of TPI
topics. Notable are modes 801 and 803. Mode 801 reports if a third
party product has been configured for this database, and mode 803 reports
if the database has been enabled for INDEXING. These two modes are worth
details.
DBINFO (base, qualifier, mode, status, buffer)
Mode 801 Returns information on the third party indexing package installed
on this database (if any).
qualifier: ignored
buffer layout: 1-20 Product name (blank if none)
(halfwords) 21-25 Version number
26-27 Date of installation (CALENDAR intrinsic)
28-29 Time of installation (TIME intrinsic)
Mode 803 Indicates if third party indexing is enabled by DBUTIL.
qualifier: ignored
buffer layout: 1 Binary zero (0) if INDEXING enabled.
(halfwords) Binary one (1) if INDEXING disabled.
There is also a range of modes reserved for third party functions beyond
the standardized functions.
Utility Program Changes
DBUTIL has been enhanced to accommodate manipulation of the INDEXING
flag. Following the configuration of indexes for the database using the
third party utility programs, indexing can be enabled for the base.
DBUTIL performs this function and can also disable indexing as necessary.
The following syntax applies to these operations:
>>ENABLE basename[/maintword] FOR INDEXING
>>DISABLE basename[/maintword] FOR INDEXING
Of course, the DBUTIL SHOW command with options ALL or FLAGS displays the
current flag setting for INDEXING.
The DBUTIL commands of PURGE, ERASE, SECURE, and RELEASE all perform the
requested function to include the TPI structures. For example, a request
to purge a database also purges the related TPI files.
DBSTORE and DBRESTOR both treat the database and TPI structures as a
single logical database and stores or restores the filesets accordingly.
DBChange Plus has been enhanced to work with TPI. For details about these
enhancements, refer to the article entitled "DBChange Plus Enhancements"
included in this Communicator.
DYNAMIC ROLLBACK WITH REMOTE DATABASE ACCESS
Dynamic Rollback for local databases was first introduced with the XL
Release 3.0 version of MPE/XL. This powerful feature of TurboIMAGE/XL
provides logical transaction insurance for your applications. Now, with
this release of MPE/iX, Dynamic Rollback can be used with remote database
access.
Dynamic Rollback was first documented in the XL Release 3.0 Communicator,
and you may wish to refer to that issue or the TurboIMAGE/XL Reference
Manual (30391-90001, third or fourth editions) for additional details.
In summary, however, three intrinsics - DBXBEGIN, DBXEND, and DBXUNDO -
constitute the external execution of Dynamic Rollback. Internally the
work is accomplished through Transaction Manager.
DBXBEGIN and DBXEND demarcate logical transactions that may consist of
one or more DBPUT, DBDELETE or DBUPDATE intrinsic calls. Of course,
DBGET and DBFIND calls may also be a part of the transaction, but since
they do not change data they are not considered part of the logical
transaction. DBXUNDO, as a single intrinsic call, can undo all
intrinsics back to the last DBXBEGIN.
When employed in a remote database environment, the program operating on
system A can define and optionally rollback transactions against a
database located on system B. It should be noted that in addition to
DBXUNDO, program aborts and system aborts cause incomplete logical
transactions to rollback. A network failure would look the same as a
program failure and rollback would occur.
As with local database access, Dynamic Rollback with remote databases
requires strong locking. Strong locking is best described as locking
that occurs as needed, but where unlocking occurs after completion of the
transaction. In the case of Dynamic Rollback the DBUNLOCK would occur
either after the DBXEND or DBXUNDO intrinsic call. The reason for this
is that, in the event of a rollback, the affected entries must still be
locked.
There are some additional design considerations in terms of logical
transaction size. Details in this area are in the ^fsTurboIMAGE
Reference Manual (30391-90001, third or fourth editions).
IEEE FLOATING POINT REAL NUMBERS
TurboIMAGE/XL now offers the ability to store IEEE format Floating Point
Real numbers and display them with QUERY. This is accomplished with a new
data type and with enhancements to QUERY.
Differences Between HP3000 and IEEE Formats
A REAL number is made up of three components: exponent, mantissa, and
sign. On HP 3000 computer systems these components are stored in 32 bits
for single precision numbers and 64 bits for double precision numbers.
The difference between the HP3000 and IEEE format is simply the number of
bits allocated to each of the three components.
HP3000 IEEE
1 bit for sign 1 bit for sign
9 bits for exponent 8 bits for exponent
22 bits for mantissa 23 bits for mantissa
1 bit for sign 1 bit for sign
9 bits for exponent 11 bits for exponent
54 bits for mantissa 52 bits for mantissa
TurboIMAGE/XL data types for REAL numbers are represented by the letter
'R' for HP3000 format and by the letter 'E' for IEEE format. As
mentioned before, lengths are either 32 or 64 bits and are represented in
16 bit halfwords, therefore, possible types are R2, R4, E2, and E4.
Data Handling By TurboIMAGE/XL
TurboIMAGE performs no type checking or verification of your data.
TurboIMAGE/XL is simply responsible for storing and delivering this data
to you at your request. Therefore, if your program passes an IEEE Real
number to TurboIMAGE and the data type is actually R (HP3000 format), the
data is stored as is. Many database applications do this type of
storage, the only drawback being that QUERY is unable to correctly
interpret the values.
Regardless of the storage methods employed, DBChange Plus has been
enhanced to allow conversions or data type changes to suit your needs.
For details about these enhancements, refer to the article entitled
"DBChange Plus Enhancements" included in this Communicator.
FOUR (4) GIGABYTE DATASET SUPPORT
Beginning with this release of MPE/iX, the maximum file size has been
expanded to 4 GB. Also with this release, TurboIMAGE/XL supports dataset
sizes to this same 4 GB maximum. The impact of this change to your
applications should be limited to operational aspects of maintenance.
All related HP TurboIMAGE/XL utilities have been enhanced to support this
new file system maximum. You may wish to contact your third party
software suppliers of database tools to ascertain their support plans in
this area.
One external change to be aware of is the sizing now performed by
DBSCHEMA. In prior versions dataset sizing was performed by DBUTIL at the
time of creation. Sizing is now performed in DBSCHEMA, and a root file
is not created should a dataset size surpass the operating system file
size maximum. The error is:
DATA SET SIZE EXCEEDS MPE/XL FILE SIZE LIMITS.
On a similar topic, but less severe, DBSCHEMA generates a warning if a
dataset size surpasses MPE/V limits; however a root file is generated.
DATA SET SIZE EXCEEDS MPE/V FILE SIZE.
CONCLUSION
Some of these enhancements will hold greater interest for you than
others, notably Indexing and Critical Item Update. Others were required
to allow your applications to grow with your increased needs as with the
larger dataset sizes. Still mthers provide support for standards or
offer entirely new functionality. With this release of MPE/iX,
Hewlett-Packard hopes these new features of TurboIMAGE/XL meet your
approval and needs.