DM/Interchange is a library of C++ classes and C functions for
handling Data Storage Sets as specified by the American Petroleum
Institute (API) publication RP66. Oilware's President, Harry E.
Schultz, directly represented Oilware on the API D9 Subcommittee
responsible for developing the new format for digital log data interchange.
This format has been known in the past as LIS-84, and LIS-V2 and
is now known as API DLIS or RP66. In addition to the DM/Interchange
library, Oilware also offers RP66 training. For more details about
training, please contact us.
 |
Supported Platforms. The primary
platform for DM/Interchange is Unix. Specifically Sun Microsystems
unix and Hewlett Packard HP-UX. Others will be added upon request.
The secondary platform is MS-DOS. DM/Interchange requires Windows
3.1, Windows 95, or Windows NT |
|
|
|
Languages Supported. DM/Interchange
is written primarily in C++, with some low level operations
written in C (low level I/O etc.). A high level Application
Programing Interface is provided for C also. The application
programmer has his choice of language interface. C may be used
exclusively, or the application program may utilize the DM/Interchange
C++ classes directly from a C++ application. A Fortran interface
has not been provided initially. It can be added if your needs
require it. |
|
|
|
Operations and Media Support. DM/Interchange
is capable of reading or writing RP66 Storage Sets. These Storage
Sets may reside on physical 9-track tape, disk files, or communications
line. Disk file storage of RP66 is supported using the recommended
RP66 stream style or the Western Atlas TIF. TIF should not,
however, be used for interchange. |
|
|
|
Object Management. DM/Interchange
internalizes RP66 Storage Set Files as a Network of Objects.
Each Object is represented as a group of Attributes and is ultimately
identified by its Object Name(OBNAME) and Object Type. The following
operations are supported on the Object Network: |
|
|
|
|
|
Object Creation. Objects can be
created and added to the network by the application program
directly, or by import from an RP66 Storage Set. |
|
|
|
Object Attachment. Attributes of
Objects can be made to reference other objects in the network |
|
|
|
Object Update. Attributes of Objects
in the network may be updated by the application program. |
|
|
|
Object Copy. Objects may be copied
within a Logical File, or between Logical Files. |
|
|
|
Object Deletion. Objects may be
deleted from the network if they are not referenced by other
Objects. |
|
|
|
Object/Attribute Interrogation.
The names of Objects and the values of Attributes of Objects
can be retrieved into the application memory space. |
|
|
|
Network Query. The network can be
queried for all Objects matching specified criteria. This is
one of the primary means of locating Objects in the Network.
|
|
|
|
Network Navigation. The other means
of finding Objects in the network is by navigation. Navigation
is the act of following references from one object to another
until Objects of interest are located. |
|
|
|
Network Verification. This operation
allows the network to be verified with respect to Object referencing
and completeness. This insures the integrity of the network.
This operation will most likely be used just prior to the export
of the network to a Storage Set. If the network is incomplete
or incorrect, a list of offending Objects is returned to the
application program. Another use of the operation would be to
verify an Object network which had just been imported. |
|
|
|
Network Creation by Storage Set
Import. An entire Object network can be created by importing
a Logical File from an RP66 Storage Set. |
|
|
|
Storage Set Creation by Network
Export. A Storage Set can be created from a selected portion
of the Object Network. |
|
|
|
Network Creation by Storage Set
Import. An entire Object network can be created by importing
a Logical File from an RP66 Storage Set. |
|
|
|
Storage Set Creation by Network Export. A Storage Set can
be created from a selected portion of the Object Network.
|
|
|
|
Bulk Data Management. Bulk data is
that data which is voluminous and uniform in its representation.
In well logging terms, bulk data is where the actual curve data
is stored. In RP66, Bulk Data is stored as a sequence of Frame
Data(FDATA) Indirectly Formatted Logical Records (IFLRs). The
FDATA records are described by FRAME and CHANNEL Objects in
the Object Network. Under DM/Interchange FDATA records are read
or written sequentially. No restriction is put on the number
of FDATA sequences which can be read or written concurrently.
UPDATE Objects will not be supported for reading or writing
of FDATA IFLRs in a Storage Set. They are being dropped for
RP66 Version 2.0, and have not been used in Data Sets produced
under Version 1.00. |
|
|
|
Logical Record Handling. DM/Interchange
provides for access directly to Logical Records. They can be
read, copied from another file, and written to an output file.
This provides an alternate view of an RP66 Storage Set, and
as such can not be intermingled with the Object/Attribute view
described in section 4. |
|
|
|
Reporting. DM/Interchange will provide
for producing a fully formatted listing of the RP66 Storage
Set being read or created. It will be possible to control the
scope of the report and the level of detail generated. |
|
|
|
Exception Handling. DM/Interchange provides exception handling
through a specialized C++ class. This class will handle all
levels of error from simple interrupts, like "End of
tape mount a new one", through warnings, to serious
and fatal errors. For each exception, the class calls an appropriate
error handling function. The default exception handlers are
provided with the class, but can be replaced by userinstalled
handlers in the same style as X-Windows callbacks. Installing
and checking the exception handlers will be part of the interface
provided by the class and its companion C interface functions.
|
|
|
|
The dmiError class also contains definitions
for debug and production versions of the DM/Interchange library.
It thus provides extensive error information during the development
phase of application programs and reduces error checking for
production releases. An optional error report can also be
produced.
|
|
|
|
This overall design allows for extensive
checking and also provides an ease of use. The application
programs do not have to check various error flags after each
call to the DM/Interchange library functions, since most errors
can be processed at the time they occur by preinstalled
exception handlers.
|
|
|
|
Encryption. DM/Interchange supports
data encryption only at a minimal level. Objects may be marked
to be encrypted when they are created by the application or
will be so marked if they were read from an incoming Storage
Set and properly decrypted. This will cause all marked objects
of each type to be grouped into sets and encrypted at the Logical
Record level. Encryption will be implemented through user installed
callbacks. These callback functions will be called by the Logical
Record Segment handling routines at the appropriate times. NOTE:
Encryption has been used in Version 1.00 of RP66, but is not
well specified relative to other, more important, aspects of
RP66. It should be used under Version 1.00 only with great care.
|
 |
|
|
|
