James,
At 6/27/00 12:46 AM -0700, you wrote:
>From there you can create DDS or SQL or
I/O internally defined specs or (gasp) IDDU.
The reality is that we already have a stable, easy way to define
our data. It's called DDS. IMHO, if IBM wants us to move to a
different method of doing something that is working well for us there are
a few points that need to be addressed:
1) How easy is it to make the transition for new code?
2) How easy is it to convert old code?
3) Functionally, does the new method contain (at least) all the
features of the old method?
4) How easy / reliable is the new method to maintain? IMHO,
this includes source control, the *exclusion* of making major changes
with a GUI that aren't reflected in text based source. (I think it's good
to have a GUI front end if it generates good source.)
Some answers:
1) Not terrible, but I find it a bit wordy and some of the keywords
are unintuitive. Also, in order do avoid the "lowest common
denominator" shortcomings platform specific extensions are needed /
used. This of course, defeats the purported "code once, run
anywhere" advantages.
2) No facility has been given to us by IBM for this function.
3) SQL definition misses functionality that DDS has, some serious
(i.e. REF).
4) Not sure, but I think it fails in that area.
Conclusion:
Don't implement a major change unless it's a completely forward
change. (As an aside, IBM made the same mistake for OV/400
users. Not all functionality available in changeover to Notes, no
easy conversion utility, etc. Even if they are trying to correct this
now, why should they have to alienate and then backpedal?)
Now before you flame me, does it really matter
to you what the
underlying physical construct is when you use an API? Do you
really
know how many places that API call went to for the information
returned?
Should you care?
That depends if you have to make changes to the underlying
DB. It may also affect the difficulty in implementing
interfaces.
-mark
midrange.com
