Justin:
Did you see my post yesterday?
http://archive.midrange.com/midrange-l/201702/msg01150.html
Store your SQL scripts in a source physical file and use RUNSQLSTM to
create the object (table/view/index) from the source.
Then, you can just issue:
DSPOBJD OBJ(MYLIB/ABCD) OBJTYPE(*FILE) DETAIL(*SERVICE)
to see this:
Display Object Description - Service
Library 1 of 1
Object . . . . . . . . . . . . . . . : ABCD
Library . . . . . . . . . . . . . : MYLIB
Library ASP device . . . . . . . . . : *SYSBAS
Library ASP group . . . . . . . . . : *SYSBAS
Type . . . . . . . . . . . . . . . . : *FILE
Source file . . . . . . . . . . . . : QSQLSRC
Library . . . . . . . . . . . . . : MYLIB
Member . . . . . . . . . . . . . . . : ABCD
Attribute . . . . . . . . . . . . . : PF
User-defined attribute . . . . . . . :
Freed . . . . . . . . . . . . . . . : NO
Size . . . . . . . . . . . . . . . . : 200704
Creation date/time . . . . . . . . . : 02/24/17 14:01:26
Source file date/time . . . . . . . : 02/24/17 14:01:18
System level . . . . . . . . . . . . : V7R1M0
Compiler . . . . . . . . . . . . . . :
More...
Press Enter to continue.
F3=Exit F12=Cancel
This clearly shows what source library/file/member this object was
created from, and the last changed date/timestamp of the source member
at the time the object was created. (This is in my opinion one of the
best features of S/38 CPF, OS/400 and IBM i ... no other platform has this.)
Then, you can just use WRKMBRPDM to look at that source member, and
type an "8" next to that member, to see:
Display Member Description
Member . . . . . . . . : ABCD
File . . . . . . . . . : QSQLSRC
Library . . . . . . . : MYLIB
Member type . . . . . . : SQL
Creation date . . . . . : 02/24/17
Creation time . . . . . : 13:59:29
Change date . . . . . . : 02/24/17
Change time . . . . . . : 14:46:55
Save date . . . . . . . :
Save time . . . . . . . :
Restore date. . . . . . :
Restore time. . . . . . :
Number of records . . . : 7
Deleted records . . . . : 0
Text . . . . . . . . . :
F3=Exit F12=Cancel
Then you know with 100% certainty whether or not this is the correct
version of the source that was used to create this object.
This is the at the very core -- the essence -- of what proper "change
management" and "version control" is all about.
If you only keep your SQL scripts in the IFS, or on some PC, (or in
some repository like Git or SVN etc.), how can you ever "know" that
you have the correct source that was used to create any given object
(table, view, index)? Not very easily, IMHO. So, then, you are back to
using "reverse-engineering" the source from the object using various
APIs, etc.
Hope that helps,
Mark S. Waterbury
> On 2/25/2017 10:17 AM, Justin Taylor wrote:
Backups. I put the risk assessment for your scenario to be very low. I think you're tremendously more at risk by keeping source that IMO has a high likelihood of being out of date.
-----Original Message-----
From: Birgitta Hauser [mailto:Hauser@xxxxxxxxxxxxxxx]
Sent: Saturday, February 25, 2017 5:01 AM
To: 'Midrange Systems Technical Discussion' <midrange-l@xxxxxxxxxxxx>
Subject: RE: Storing source as DDL instead of DDS
We don't have any reason to keep DDL source at all.
What happens if a DDL described database object gets lost, i.e. an Index or a view or even worse an view based on multiple views gets deleted.
What if a trigger or constraint is deleted?
How will you recreate it, if the object does no longer exist, so reverse engineering is no longer possible?
Mit freundlichen Grüßen / Best regards
Birgitta Hauser
"Shoot for the moon, even if you miss, you'll land among the stars." (Les
Brown)
"If you think education is expensive, try ignorance." (Derek Bok) "What is worse than training your staff and losing them? Not training them and keeping them!"
"Train people well enough so they can leave, treat them well enough so they don't want to." (Richard Branson)
midrange.com
