Discussion:
change from DDS to DDL
(too old to reply)
Mike Cunningham
2014-10-22 14:18:58 UTC
Permalink
Raw Message
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 aft
er 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-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
Charles Wilt
2014-10-22 14:26:20 UTC
Permalink
Raw Message
​​Generate Data Definition Language (QSQGNDDL) API

Same thing iNav uses when you right click and do , Generate SQL DDL
Post by Mike Cunningham
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 subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-***@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-***@midrange.com
Before posting, please take a moment to review the archives
at http
Luis Rodriguez
2014-10-22 14:29:26 UTC
Permalink
Raw Message
Mike,

You can use iNav in order to recreate the source for any SQL object
(tables, views, indexes, functions, etc). Also, there is an API (I don't
remember the name right now) that does the same thing, as several user
utilities out there that use the it (the API). I seem to remember a
RTVSQLSRC.

HTH,

Luis

Luis Rodriguez
IBM Certified Systems Expert — eServer i5 iSeries
--
Post by Mike Cunningham
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 subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-***@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-***@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/mid
Buck Calabro
2014-10-22 14:39:22 UTC
Permalink
Raw Message
Post by Mike Cunningham
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?
Yes, exactly.
--
--buck

'I had nothing to offer anybody except my own confusion' - Jack Kerouac
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
Loading...