RE: Storing source as DDL instead of DDS

That will identify whether the source matches, it doesn't guarantee that it does.



-----Original Message-----
From: Mark S Waterbury [mailto:mark.s.waterbury@xxxxxxxxxxxxx]
Sent: Sunday, February 26, 2017 11:28 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: Re: Storing source as DDL instead of DDS

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?