The migration from a Production IDD to a Test IDD is, generally, a restore function, and, as such, is very different, philosophically, from migrating from Test to Production. Not only is change control not an issue, but the AMU's standard enforcement of some change control may even get in the way. In addition to the philosophical difference, there are technical considerations that will, most likely, cause the establishment of different procedures for these two types of migrations.
If none of the entities to be migrated exist in the Test IDD, then there is no problem and you can ignore this whole section and just use the same general procedure as migrating from Test to Production.
The determination of migration status is, by default, based upon in which IDD the
entity has been most recently updated. This works very well when things are always going in
the same direction. For example, if you always migrate from Test to Production, modified
entities have a more recent update date in the Test IDD until they are migrated, at which
time the Production update date becomes more recent. Subsequent migrations would not select
these entities until they were, once again, modified in the Test IDD.
If this process is reversed, the entities updated more recently in the Test environment, which
are probably the exact ones which you wish to restore, would not be migrated (since the
Test update date is more recent).
In order to replace entities that already exist in the Test IDD, the AMU requires the replacement of
all affected prerequisite entities . This is especially
a problem with globally (or widely) used elements and, to a somewhat lesser extent, records. For
example, replacing an element requires replacing all records that use that element, and
replacing all maps that use all those records. There are three big problems in this regard.
The precise solution is dependent upon your environment and exactly what you want to accomplish. Use the following suggestions to devise your own strategy.
If there is no concern with changes to documentational relationships to entities, such as class/attributes, users, user-defined nests, comments, descriptions, etc., using structural comparisons is the recommended method. This limits the migration to only those entities which are structurally different.
More migration problems originate with elements than any other entity type. This is simply because there are a larger number of elements than any other entity type, and because there are logical and technical preqrequisites for replacing elements.
If you are certain that no changes have been made to any elements and that all elements are already in the Test IDD, you can specify OPTIONS=ELEMENTS=BYP in Phase I to bypass elements.
Elements, by default, will not be replaced unless all prerequisite records (and their maps) are available for migration. If you would like to replace the elements even if prerequisite conditions are not met, you may specify OPTIONS=REPELEM=EVEN in Phase I. Note that this is not recommended because it leaves some inconsistency between the element definition and some record element definitions. However, as long as you are aware of the ramifications, and address them as necessary, you may find it more expedient.
To simplify the process, you may also wish to bypass other entity types. Some Entity Selection Options allow BYP to be specified.
Another method of bypassing entity types is simply to drop them from the sort following Phase I (LADAMU05). Entities dropped at this point are as if they never existed in the migration at all. They appear on no reports and are not analyzed in any fashion. Note that this could cause problems if, for instance, you drop (or bypass) all elements and some of the elements do not exist in the Test IDD. So you must be sure that any dropped entity types have no adverse effect on prerequisite entities.
If you find it necessary, you can force the migration of certain entity types by specifying REVIEW for the appropriate Entity Comparison Option(s). If, for example, you wanted to ensure the migration of a dialog, its map, and its processes, you could specify (in Phase I)
OPTIONS=COMPARE=STANDARD,PROCOMPR=REVIEW,MAPCOMPR=REVIEW,MODCOMPR=REVIEWAll other entities would be compared in whatever fashion had been previously specified (or defaulted), in this case STANDARD.
Use Selection Criteria Statements such as MODULE= or MAP= (in conjunction with the appropriate REVIEW option above) to force the migration of only those specific entity occurrences that you wish to restore. Of course, you could, similarly, manually migrate these entity occurrences.