Justin:
Regarding your statement:
... although I don't think it ensures the source matches the object.
Using RUNSQLSTM with a source physical file member makes it possible to
determine whether the source member still "matches" what was used to
create the object, because if anyone changes or modifies that source
member (since then), that source member's "last-changed" date/time stamp
will now be altered and will no longer match what is shown by DSPOBJD,
for example:
DSPOBJD OBJ(MYLIB/ABCD) OBJTYPE(*FILE) newETAIL(*SERVICE)
and look at this line in the output display:
Source file date/time . . . . . . . : 02/24/17 14:01:18**
Then issue WRKMBRPDM on the source file, and then type an "8" next to
the desired member to see when it was last changed, e.g., look for
these lines in the output display:
*Change date . . . . . . : 02/24/17 **Change time . . . . . . : 14:46:55 *
If this date/time does not "match" the date/time seen in the DSPOBJD
above, then the source might no longer "match" what it was when it was
used to create the object, and so this source member is now "suspect"
(further investigation is warranted). (Notice that someone could have
edited the source member, but not really made any changes, or just added
comments, and then re-saved the member, so the actual SQL DDL may in
fact still be valid. But the member's "last-changed" date/time will
now be different.)
At that point, you could use one of those tools that can generate the
equivalent SQL DDL from the actual database object(s), and then compare
that to the existing source member contents, or just replace that member
with the newly generated SQL DDL source (plus any new changes), when
you are ready to promote your changes to "live."
(If using a change management tool, it should have automatically
archived a copy of the correct source, at the time the change was
"promoted" into the "live" environment, so you should always be able
to reliably retrieve the "correct" source from the change management
system.)
As to your statement:
... wouldn't you have to hand-code all your DDL?
I did not say anything about what tools you might want to use for
creating SQL DDL scripts. You could use STRSQL in a 5250 session, and
then "cut and paste" the SQL statement(s) into SEU, or you could use any
of the GUI tools such as in RDi or IBM i Navigator, etc.,and then just
use FTP to copy the SQL DDL script from the PC to a source physical
file member, when you are ready to promote (install) the changes into
the "live" production database schema. (In other words, you probably
"test" your SQL scripts in some "development" or testing" library,
before applying them to your "live" production databases/...//
/All the best,
Mark S. Waterbury
> On 2/26/2017 10:51 AM, Justin Taylor wrote:
That would make it easier to maintain source, although I don't think it ensures the source matches the object. Also, wouldn't you have to hand-code all your DDL?
midrange.com
