| Let's get real!
For Adabas/Natural, the user would have to write a template for
an entirely new language, Natural. Every time new elements were
introduced, the user would have to change or expand the template.
While this could be done, I doubt that many customers would be willing
to expend the effort.
Adabas/Natural uses PREDICT as its active Dictionary.
CMS could be used to store source, but I'm not sure that the Natural
compiler could then find the code to compile since CMS stores original
code first, then only the editing changes to the original. I'm not
sure that Natural could decipher the format.
MMS might be useful, but the advantage of a 4GL is that it is
non-procedural. Using a procedural module map compiling technique
runs philosophically counter to 4GL advantages.
Since Adabas is doing the compiles, SCA is useless.
Without MMS and CMS for building and storing, would you really want
to try DTM. I can't imagine PCA working with the Adabas utilities
doing the compiles.
Oracle is much the same. It uses SQL*Dictionary as its active
dictionary.
SQL*Forms is a 4GL. It too would require a brand new template. Would
the template and LSE give the user advantages over the screen-based
system used in SQL*Forms? Not likely.
One of the problems with 3rd party databases is that they cost us
huge amounts of downline software business like VAXset. But I think
that retrofitting VAXset for each particular database is an exercise
in futility.
---- Michael Booth
|
| Being new to Digital and not yet master of the TLA's (Three Letter
Acronyms), I my stumble a little here, but let me give it a shot.
NATURAL is written and positioned as a 4th generation application
development system, of which a major part is the 4th generation
language, also called NATURAL. A customer attempting to use some
of Digital's development products to enhance NATURAL would be
abdicating the benefits that he bought NATURAL for in the first
place. NATURAL contains its own editors (not language sensitive),
its own screen generator, a library management system (not very
good, but for both source and object), and is very integrated with
the dictionary, Predict. Needless to say, source, object and dictionary
information is stored in ADABAS (no E) and is verrrry efficient
in terms of retrieval, compression, etc. But, if any one of these
functions is managed by something other than ADABAS/NATURAL, the
integration falls to pieces. Some parts of the system simply would
not know where other pieces are. As things like SUPERNATURAL, NATURAL
ELITE, NATURAL SECURITY, and CONNECT are added to the environment,
the interdependencies magnify geometrically. This gets Digital in
two ways: 1) Rdb and associated products are locked out and 2) since
every one of the above mentioned products is written in NATURAL,
each will run on IBM without changing a thing. Your customer now
has an open door to try a 9370 or worse.
|
| one more note. NATURAL contains a language, among many other
facilities, just like COBOL does. It compiles to object code, but
does require runtime modules (as does COBOL, at least in the IBM
world). It does not generate a 3gl, that would be like COBOL generating
assembler before compiling. Most NATURAL functions perform fairly
well on the VMS platform, though the new version has many performance
problems on the IBM platform.
Jamey Nordby
|