Re: change from DDS to DDL

One of the things holding us back from the move to DDL is our current
process (homegrown) for making changes to physical files/tables. We have
had a utility we have used for years where we enter the name and library of
a file we want to change, we change the DDS associated with that file, then
after our nightly backup when we know for sure no one is using the file, we
do a CHGPF command for every record in the file. Since we have a standard
that we never use a physical file in an application and we never use
logical files that include all fields by default, this process works very
well.

Were we currently use DDL to create tables we use the Navigator GUI to
define the table and make changes. That requires an exclusive lock on the
table and so it means we have to be here at a time when the file is not in
use. Usually very late night or very early morning. The only way I can
think of to replicate our nightly process that does the CHGPF is to create
an SQL script source file with all the SQL commands needed (which sometimes
can be 4-5 commands just to add a field to a table) and then instead of
executing CHGPF we do a RUNSQLSTM? And the second part is the DDS has been
a good way to document when the layout of the file is and in DDS world you
are forced to change the documentation before the change is implemented.
What would be the best way to document the new table layout after executing
the RUNSQLSTM? My thoughts were to use DSPFFD to an output file. Is there
an SQL command that can be used to generate all the SQL commands needed to
recreate a table if that wer
e ever to be needed?
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.