Re: SQL statements for physical and logical files

Yes there are risks, and they're not to be discarded lightly.

But I'd like to discuss what is perceived as "significant operational
improvement".

Is it performance?
There are some defaults in DDL which are more modern than those defaults
in DDS. Blocking kind of stuff. Some of these are not even in DDS but
are more in the way of how you generate the end object from DDS. And
since every shop has their own MAKE tool (if anything) turnover seems to
imply that something will get lost in the shuffle.

Is it less error prone?
Depends on your definition of the error. We've discussed the problems of
getting past previous poor coding techniques. But I also argue that not
getting decimal data errors for data fouled up during conversions, data
feeds and whatnot is a big thing

Is it easier to code integrity?
Let's face it, the CHECK keyword in DDS is a joke compared to DDL check
constraints.
I also argue that having check, referential, and other constraints in the
DDL increases the likelihood of people actually using them. Most of these
(except maybe a primary key constraint) are not available in DDS. Sure,
you can bolt them on with ADDPFCST but since that's outside of DDS the
likelihood of it being used decreases dramatically. And since every shop
has their own MAKE tool (if anything) turnover seems to imply that
something will get lost in the shuffle.

Rob Berendt