Re: QDDLSRC - put library names in source?

No. I have no source file named QDDLSRC. I permanently store DDL source in
QDDSSRC.


The way I work is this - suppose I need to add field(s) to a file (some of
you will barf at what you're about to read, but I haven't had a problem with
this method, ever. See caveat at the end.):


1) Copy the DDL for the table/indexes/views from the production library to
my test library.

2) Change the DDL in the test library to include the new field(s).

3) Create the table/indexes/views in the test library.

4) Set the authority on the table/indexes/views in the test library to match
the authority on the corresponding object in the production library.

5) Set the table/indexes/views in the test library to LVLCHK(*NO). (It's OK
to breathe.)

6) When the system is acquiesced (usually very early AM or late at night), I
do the following back-to-back-to-back:

a) Do a CPYF FROMFILE(<prodlib>) TOFILE(<testlib>) FMTOPT(*MAP).
b) Move the indexes/views from test to production
c) Move the table from test to production
d) Move the changed DDL source from test to production

Note that I now have production files, with the new field(s), at
LVLCHK(*NO).

7) I compile all production programs that touch this table/indexes/views.

8) Set the table/indexes/views in the production library to LVLCHK(*YES).


The table/indexes/views are now in production with LVLCHK(*YES), though no
program changes have been made to utilize the new field(s).

I believe that when I'm only _adding_ field(s) to a file, the above method
is less prone to error than copying all DDL and program source to the test
library, compiling, and then needing to put the table, indexes, views,
programs, and all associated source into production in one fell swoop.

For making _use_ of the new fields, I then do a CRTDUPOBJ of the
table/indexes/views into the test library of my choice, then copy the source
of only the programs will make actual use of the new field to the test
library and the program/test/change cycle commences. I test with STRDBG
UPDPROD(*NO). When finished testing, only the program source and objects
need to be moved into the production library. The table/indexes/views in
the test library are blown away.


Caveat: Obviously, I cannot do the above if I'm either deleting a field or
changing an existing field in the file. In that case I have to do the "one
fell swoop" route.



On Wed, Aug 11, 2010 at 3:21 PM, Gqcy <gmufasa01@xxxxxxxxx> wrote:

then when you do want to create the production object, you change the
QDDLSRC?

I am thinking that we won't put the DROP statement in the source, but
commenting it out may work as well.


Jeff Crosby wrote:

When I converted all files from DDS to DDL a few years back, I did 2

things:

1) I still keep the source in QDDSSRC even though it is DDL. That way,
during the project (which took a year), all source that referred to a
physical file/table or logical file/index/view was stored in the same
place. Now that I am done, I still keep it in QDDSSRC along with display
and printer file DDS. I saw no real benefit in separating them.

2) I hard coded the library name in the DDL. And the library name I use

in

the source is JEFF which is the name of my test library. In this way, I
can't accidentally run that DDL and replace a production object. (I have

a

DROP TABLE/INDEX/VIEW coded in the source prior to the CREATE
TABLE/INDEX/VIEW. The DROP statement is also normally commented out like
this -- DROP. Yes, I'm a belt-and-suspenders kind of guy.)

Just my opinions.



On Wed, Aug 11, 2010 at 1:55 PM, Gqcy <gmufasa01@xxxxxxxxx> wrote:

When we migrate our Source to DDL, should we have the library name in
the CREATE TABLE/INDEX/VIEW string?

CREATE TABLE xyzlib/abcfile...
-or-
CREATE TABLE abcfile
(and use current library as where the file will be built)

How do we create a test data library?

-gerald


--
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.

--
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.