.PAGE SIZE 62, 90
.LEFT MARGIN 10.RIGHT MARGIN 90
.CENTER
^&VAX-DATATRIEVE to DATATRIEVE-11 Conversion Panel\&
.BLANK 2.PARAGRAPH
This presentation will give some guidelines for moving applications from
VAX-DATATRIEVE to DATATRIEVE-11 (including PRO/DATATRIEVE), or developing
applications which will run on both types of machines. If possible, it's easier
in some ways to develop the application on the PDP-11 first as it is now
virtually a sub-set of VAX-DTR, but this isn't always possible. Anyone
contemplating a migration should certainly read the DTR-11 manuals, especially
the sections on optimization.
.PARAGRAPH
As this session is a panel, only a brief overview could be prepared ahead
of the session.
.PARAGRAPH
First, the bad news. DATATRIEVE-11 does ^&NOT\& have:
.BLANK.NO JUSTIFY.NO FILL.SPACING 2
CROSS
PLOTS
FORMS
FN$ functions
RUNNING COUNT
STANDARD DEVIATION
DOMAIN TABLES
CHOICE
Some data types.
Hirarchical Dictionary.
.BLANK.JUSTIFY.FILL.SPACING 1
and the big problem: DTR-11 has restricted internal work space (POOL). There are
also some minor annoyances, such as the inconvienient editor, and the inability
to interrupt and return (no Control-Y and SPAWN).
.PARAGRAPH
The restrictions are not as bad as they might first appear. Not having
CROSS, FN$ functions, and running count is annoying, but usually the same thing
can be done by approaching the problem another way, such as using A VIEW rather
than a CROSS. Not having domain tables may make changing the data in the table
more difficult, but the same function may be obtained with dictionary tables,
VIEWs, or explicetly accessing the data in a domain. The restriction is data
types is more cosmetic than real: as there are no G__Floating or H__Floating
numbers on PDP-11 systems, there really isn't any need for them within DTR-11
(but see some comments on data file migration below). In many cases, the same
data type is available under a different name: for example,
.BLANK
10 FIELD1 PIC 9(5) USAGE LONG.
.BLANK
is the same as
.BLANK
10 FIELD1 PIC 9(5) USAGE INTEGER.
.BLANK
The former is available in VAX-DTR only, but the latter is available in all
versions of DATATRIEVE, and should be used if an application is to be migrated.
The difference is that with the former you are assured of obtaining a 4 byte
integer: with the latter, you may have a 2, 4 or 8 byte integer depending on the
size of the PIC clause, so you have to be a little more careful about your
record definition.
.PARAGRAPH
This really points out the fundamental difference between programming in
VAX-DTR and DTR-11: with VAX-DTR, you can be fairly sloppy and your application
will still work. There is a large amount of virtual work space, you can CROSS
domains over any key, record definitions may be as large as you wish, you can
leave many domains READY, etc., and the application will still work, though you
may degrade performance on your system or have slower response times than you
would with a "tighter" design. With DTR-11, there are not as many short cuts,
and you have to think more about your design. The limited amount of pool space
means that record definitions can't have unneccesary fields or clauses. The fact
that the length of an INTEGER variable depends upon the PIC clause means you
have to pay a little more attention to your data and know a little more about
it. The limited pool also means you can't have domains READY when they aren't
needed (though the time to READY a domain usually appears faster on a PDP-11
than on a VAX), and the fact that you have to use a VIEW rather than a CROSS
often requires that you check more carefully into the relationship between the
two domains, so you may be less likely to use a non-keyed field to associate the
two domains and avoid a very common performance trap.
.PARAGRAPH
Another trap to avoid if the actual data files are to be transported from the
VAX to the PDP-11 (as opposed to transporting only the record and domain
definitions and loading in new data) is word alignment. On the VAX, any data
type can start in any location: on the PDP-11, certain data types (INTEGER,
REAL, DATE) must start on word (even byte) boundaries. When you define a record
in DTR-11, if such a field does not fall on an even boundary, DTR-11 will insert
a filler byte to make it line up properly. You do not receive any warning about
this happening, however. VAX-DTR does not do this unless you use the
ALLOCATION#IS#LEFT__RIGHT clause in your record definition, so if you defined a
record without this clause, and have an INTEGER, REAL or DATE that falls on a
byte boundary, and try to read it after moving it to DTR-11, the data will not
align properly and will look like "garbage" when you print it (you will probably
also receive a message about the record length not matching the file due to the
extra filler bytes). You may wish to create a new domain on your VAX with the
alignment clause and restructure the data in the domain before exporting it to
DTR-11.