Re: Convert sources for RDi

On 21-Nov-2014 16:17 -0600, Voris, John wrote:

<<SNIP>> I do encourage as a big up-front change is to make sure you
have taken advantage of the longer source-file formats. Be sure
going into the future that you have your source files defined as
112 total in CRTSRCPF cmd.

Due to some corporate policies about change management,
moving source all at once is discouraged as new source dates are
generated. (Member dates change even though dates on individual
source lines do not change. <<SNIP>>

An enhancement was made to allow the source-change date information to be carried to the target member from the source member in a copy request; that should resolve most concerns for the CM. The Copy Source File (CPYSRCF) command enables the specification of the special value *FROMMBR on the Source Change Date (SRCCHGDATE) parameter. Starting with v6r1 [IBM i 6.1] that the maintaining of the source last-updated date is the default effect when copying an existing member into a new\replaced member. Copying all of the member.data from the old source file with the shorter record length to the new source file with the longer record length and no existing members should enable the up-front change: CPYSRCF FROMFILE(old_srcF) TOFILE(new_srcF) FROMMBR(*ALL) TOMBR(*FROMMBR) MBROPT(*REPLACE)

<http://www.ibm.com/support/knowledgecenter/api/content/ssw_ibm_i_71/cl/cpysrcf.htm>
_Copy Source File_ (CPYSRCF)
"The Copy Source File (CPYSRCF) command copies a database source ..."

A modified last-changed date for a member is an effect from many possible origins, for various change activity having nothing to do with the source data itself. Any CMS using the member-changed date rather than the source-changed date for source members is likely, at least somewhat flawed. The changed member per someone having added a new developer as an authorized party for example, should not cause any CM feature to [falsely] believe that the source has been changed.

Note: The Member Level Identifier is something beyond the source change date that might legitimately be tracked to a CMS; i.e. in contrast to any CMS inexcusably depending on the member-change date to infer source changes. Like the addition of the SRCCHGDATE parameter, there was an additional parameter To Member Identifier (TOMBRID) for which a specification of the special value *FROMMBR will effect maintaining that LvlId. The default for the TOMBRID parameter however, was chosen to be consistent with the past rather than effecting an incompatible change as with the SRCCHGDATE default. The default effect is to have a new MbrLvlId generated (*GEN) for a newly created member. Thus a revision to the up-front change might [best be or] require that the following revision is made to the invocation shown earlier\above: CPYSRCF FROMFILE(old_srcF) TOFILE(new_srcF) FROMMBR(*ALL) TOMBR(*FROMMBR) TOMBRID(*FROMMBR) MBROPT(*REPLACE)