HP 3000 Manuals HP 3000 Manuals
Compatibility Considerations
There are some compatibility issues for application programs of which you
should be aware. These compatibility issues are discussed below.
ILR and MPE/iX
ILR is enabled differently on MPE/iX than on MPE V/E. Due to these
differences, ILR should be disabled before making a copy of a database
you want to move across systems.
If an MPE V/E-based system fails during the execution of a DBPUT or
DBDELETE, broken chains can result and the structural integrity of the
database is lost. Enabling ILR on the MPE V/E-based system guarantees
the structural integrity of the database since TurboIMAGE/V logs each
DBPUT and DBDELETE to the ILR log file (DBFILE00) before modifying the
database. If the system fails during the execution of the DBPUT or
DBDELETE, the ILR file is used to recover the database.
On the MPE/iX based system, TurboIMAGE uses the operating system services
(transaction manager) to ensure that there are no broken chains in the
database. The structural integrity of the database is preserved even if
ILR is not enabled on MPE/iX.
Enabling ILR in MPE/iX simply causes the operating system to flush some
portions of memory to disk at the end of each DBPUT or DBDELETE. The
result is that less work might be lost in the event of a system failure.
Known Incompatibilities in the Status Array
* New status codes all are negative (-) values.
* New error messages go with the new negative status codes.
* When running in CM, status array [10] is the PB-relative address
pointing to the TurboIMAGE/XL stub and not to the NM intrinsic.
* When running in NM, the database address is 32 bits long.
* When running in NM, the PB-relative and DB-relative offsets are
not returned in the status array.
DBEXPLAIN and the TurboIMAGE/XL Status Array
For NM programs, addresses are 32 bits rather than 16 bits. Since the
status array is not large enough to hold all the information, some
information is saved in run-time control blocks (RTCB). The information
stored in the RTCB is from the recently executed intrinsic.
Because of this arrangement, you must call DBEXPLAIN immediately after
the intrinsic which encounters an error in order to obtain an accurate
display. When migrating application programs, look for multiple status
arrays, since your program must use more than one status array to create
this situation.
For example in CM programs DBEXPLAIN is compatible with the TurboIMAGE/V
implementation with the exception that the PB-offset of the CM stub is
returned instead of the offset of the intrinsic.
For NM programs the status array is not compatible, however the display
for DBEXPLAIN is compatible. For TurboIMAGE/XL DBEXPLAIN merges the
status array and RTCB values. However be aware that the RTCB values are
valid only for the last intrinsic. Therefore, DBEXPLAIN must be called
before any other TurboIMAGE/XL intrinsic to obtain the correct status
array. Values from an old status array cannot be saved and used to call
DBEXPLAIN at a later time.
Native Mode Code Issues
There are two issues associated with running application programs in NM:
* Real data types
* Data alignment
Real Data Types
TurboIMAGE/iX is insensitive to the difference between HP 3000 and IEEE
real data type formats (floating-point decimals). However, other
products are sensitive to the differences. Some of the products which
are sensitive are:
* CM compilers
* QUERY/CM
* DBchange/V
* VPLUSN
* other utilities
The NM compilers available on MPE/iX have options to indicate the real
data type format.
Note that 900 series coprocessors require the use of IEEE real data
types.
Real data type formats can be converted by customer code or utilities
using the HPFPCONVERT intrinsic.
Data Alignment
NM programs must use the HP 3000 compiler options. TurboIMAGE/XL data
buffers and internal data structures are still aligned on 16-bit
boundaries.