HP 3000 Manuals HP 3000 Manuals
Chapter 5 DATABASE TOOLS HP30391C: TurboIMAGE/XL by George Allen, Information Technology Group Implementation of TurboIMAGE/XL provides users of the HP 3000 family with a familiar, award-winning, network based DBMS which in turn maximizes the rich feature set provided by Hewlett-Packard Precision Architecture and the MPE`XL Operating System. TurboIMAGE/XL has been enhanced since Release 1.0 for additional performance gains. MIGRATION PATH FOR TURBOIMAGE/V TurboIMAGE/XL is the migration path for current TurboIMAGE/V applications. The external specifications for TurboIMAGE/XL have been designed to match as closely as possible with those of TurboIMAGE/V. The structure of the rootfile and data sets has not changed. This means that migration may be as simple as an MPE V STORE and MPE`XL RESTORE of the database and all other files required by the application. After restoration of the files, the application will work in compatibility mode, provided by TurboIMAGE/XL and the MPE`XL Operating System. Migration directly from IMAGE/3000 is possible, but it is strongly recommended that IMAGE/3000 databases first be converted to TurboIMAGE/V before converting to TurboIMAGE/XL. TurboIMAGE/V was first introduced with the U-MIT Release of MPE V. Users who are migrating from a U-MIT or later based version of the operating system will already be running TurboIMAGE/V. OPERATIONAL DIFFERENCES Wherever possible, the design of TurboIMAGE/XL has maintained compatibility with TurboIMAGE/V. From an externals point of view, this goal has been met with great success. For some users, the following issues may warrant further investigation. The TurboIMAGE/XL Database Management Reference Manual (P/N 32215-60002) is an additional source of information. Data alignment TurboIMAGE/XL data items continue to be packed into data entries on 16 bit boundaries. For example, a data item of type X3 is not allowed on either implementation of TurboIMAGE since this would result in an item length totaling an odd number of bytes. For TurboIMAGE/V, most language interfaces to the database intrinsics handled this type of 16 bit alignment quite naturally. For TurboIMAGE/XL however, applications which are recompiled should be carefully reviewed for differences in alignment and packing of parameters used for calls to the database intrinsics. Native mode compiler options have been provided to assist in this effort. For example, the $HP3000_16$ string in an HP PASCAL source file will provide this service. REALS: Data Items of Type R The format of real data items (R2, R4) continues to be HP 3000 real number format, although the default real number format for new native mode program development is IEEE format. Either these data items need to be converted programmatically or the application must continue to use HP 3000 real number format. A new intrinsic, HPFPConvert, has been provided to allow for programmatic real number conversions of one format and/or precision to another. For preservation of the HP 3000 real number format, native mode compiler options are provided. Once again, the $HP3000_16$ string in HP PASCAL source will provide for HP 3000 format reals. Status Array Some elements of the status array returned by the database intrinsics have changed or been eliminated. If DBERROR and DBEXPLAIN are used for analysis of the status array, then TurboIMAGE/XL will work properly. Applications which directly manipulate or depend upon the contents of the status array may need alteration. The TurboIMAGE/XL return status (the first word of the status array) may also contain previously unencountered values. For instance, a return status of -177 for TurboIMAGE/XL means that upon attempting a DBOPEN, it was determined that the logfile and database resided in different volume sets (see below). If the application tests for a non-zero return and then calls DBEXPLAIN, the error can be handled gracefully. However, if specific values are tested for, then this new error may need to be added. As always, the recommended and supported way of analyzing the contents of the status array is to call DBERROR and/or DBEXPLAIN. These intrinsics will interpret the status array contents and format the error information. It is important to note that calls to DBERROR and/or DBEXPLAIN should be made right after the call which returned the error. If another database intrinsic were called after the intrinsic which returned the error, then some information from the status array might have been lost. RDBA: Remote database access Remote database application is available via NS/3000 only. DS is not supported on MPE`XL. RDBA from TurboIMAGE/V to TurboIMAGE/XL is supported. DATABASE INTEGRITY AND RECOVERABILITY The externals of database integrity and recoverability features for TurboIMAGE/XL have changed minimally. Autodefer, ILR, and rollforward & rollback recovery are still available. Autodefer offers the highest level of performance in exchange for possible loss of logical and/or physical database integrity due to a system interruption. Note for the default mode of operation, i.e., no ILR, no autodefer and no logging, that physical database integrity is now assured due to transaction management features of MPE XL. In short, this means the end of broken chains! ILR is NOT necessary for physical integrity. ILR should be disabled on MPE V before migrating to MPE XL. If ILR is still desired, it can then be enabled on MPE XL. Rollback and rollforward recovery are still implemented in conjunction with MPE User Logging. DBRECOV is used to process the user logging file after a system interruption. For rollback recovery, the user logging file must reside on the same volume set as the database. Furthermore, this must be the system volume set if the user logging is done to tape. Because the unit of recovery for MPE XL transactions is the volume set, the database and logfile must be kept within the same volume set. In the case of rollforward, this restriction is not necessary since a backup copy of the database would have been restored and the transactions from the logfile reapplied.