There is no user input into this phase; it may be executed immediately upon successful completion of Phase I.
LADAMU10 compares each selected entity in the EXTRACT file against the object IDD and assigns a migration status. Duplicate entity occurrences are flagged as such (or dropped if OPTIONS=DUPS=DROP was specified in Phase I). For entities assigned the migration status of REVIEW, the object IDD is read and all prerequisites for its replacement are written to the REPLACE file.
If any of the structural (or full) comparison options was specified in Phase I, then LADAMU10 will read both the source and object IDDs at the same time to perform its complete structural comparison. See Using Structural Comparisons for important details on the use of this facility.
LADAMU11 cross references entities to be replaced with their prerequisites for replacement.
LADAMU12 compares the EXTRACT file with the REPLACE file to determine if all prerequisites for the replacement of modified entities are present. See Replacing Modified Entities for more details.
Each selected entity is assigned a migration status.
Each selected entity in the EXTRACT file is compared against the object IDD totally independently of any entity relationships. The entity is obtained CALC. If it does not exist, the migration status of YES is assigned; if it does exist, specific comparisons are performed dependent upon the entity type and the Phase I OPTIONS.
Dependent upon the entity type and Phase I OPTIONS, three date comparisons may be performed. We will call these dates date last updated, prog last updated, and load last updated, and use the term comparison date to mean any of the above.
If the source comparison date is more recent than the object comparison date, it is considered to be an inconsistency. The theory is that you always migrate in the same direction and if the source comparison date is more recent, then the entity must have been changed.
If OPTIONS=COMPARE=REVIEWEQ has been specified in Phase I, then if the source comparison date is more recent or equal to the object comparison date, it is considered to be an inconsistency. Note that the AMU compares not only date, but date and time when time is available.
Even though Phase I does not permit a specification for each entity type, OPTIONS=COMPARE= (which defaults to STANDARD) encompasses all entity types. So, at the completion of Phase I, each entity type has been assigned a comparison option.
ADSA Application Only load last updated is compared. DIALOG For PROCOMPR=STRUCTURE, the names of the component records, modules, map and subschema are compared in the same sequence that they would appear in an IDMSDDDL DISPLAY PROGRAM statement. ELEMENT For ELECOMPR=STANDARD, the primary picture and usage, element length, and first 20 characters of initial (or 88-level) values are compared. Note that if the picture in both dictionaries is alphanumeric (X) and the usage is display, then the comparison of the picture will be bypassed. This eliminates the utility finding inconsistencies with equivalent pictures such as PIC X and PIC X(0001). Note, also, that group elements have no picture, usage, or initial value. If the length of the group element and the date comparison are both consistent, then no differences are detected even if the source group element has entirely different subordinate elements than the object group element. For ELECOMPR=STRUCTURE, the length, all primary and alternate picture definitions (including picture, usage, justification, blank when zero, and sign specifications), and all initial (or 88-level) values are compared. For group elements, the names and versions of its subordinate elements are compared in the same sequence that they would appear in an IDMSDDDL DISPLAY ELEMENT statement. FILE The record format, record size, and block size are compared. MAP For MAPCOMPR=STANDARD, the date last updated is the most recent of DATE-CREATED-098, DATE-LU-098 and MAP-DATE-098/MAP-TIME-098 (map compile date). Note that MAP- DATE-098 is only updated by the mapping compilers if a critical change is made to the map. Reference the IDMS-DC/UCF Mapping Facility for further details. For MAPCOMPR=STRUCTURE, the name of the owning panel, number of data fields, number of records used, cursor placement, write control character, attributes for correct and incorrect fields, and map attributes (pageable/non-pageable, editting on/off, message field exists/does not exist) are compared. Additionally, each map field is compared in its entirety (except for name), and the names of map records are compared. MESSAGE For MSGCOMPR=STRUCTURE, the message text, destination, descriptor codes, severity level, and routing codes are compared for each message line. MODULE For MODCOMPR=STRUCTURE, each line of module text is compared. PANEL For MAPCOMPR=STRUCTURE, the supported devices and, for each panel field, the location (row/column), attribute byte, and literal value are compared. EDIT MODULE For PROCOMPR=STANDARD, the date last updated is the most recent of DATE-CREATED-051, DATE-LU-051, and PROG-DATE-051 (program compile date). For PROCOMPR=STRUCTURE, the names of the component records, modules, maps and subschema are compared in the same sequence that they would appear in an IDMSDDDL DISPLAY PROGRAM statement. RECORD For RECCOMPR=STANDARD, the record length and total number of record elements are compared. For RECCOMPR=STRUCTURE, the record type, record format,alternate picture type, and view are compared. Additionally, for each record element, the name, length, picture, usage, occurs, alternate picture type, justification, blank when zero, and initial (or 88-level) value are compared. TABLE For TABCOMPR=STRUCTURE, the entire table definition is compared.
If OPTIONS=COMPARE=STRUCTURE, OPTIONS=xxxCOMPR=STRUCTURE, OPTIONS=COMPARE=FULL, or OPTIONS=xxxCOMPR=FULL was specified in Phase I, then LADAMU10 will read both the source and object IDDs at the same time to perform its complete structural comparison. In order to do this, the dictionaries must be uniquely addressable by different DBNAMEs. So, at least one of the dictionaries must be addressable by some DBNAME, i.e. either SRCDICT or OBJDICT must be specified in Phase I. If you are migrating between primary dictionaries and you wish to perform the structural comparison, you must take the trouble to define a DBNAME for one of those dictionaries. Note that you will still be able to address that dictionary as a primary dictionary, but you will be able to address it as a secondary dictionary as well. You may either define your object IDD as a secondary dictionary in your source CV or define your source IDD as a secondary dictionary in your object CV. Or, if local mode execution is intended, you may just create a totally separate DBNAME table, DMCL(s), and subschema(s).
At run time, LADAMU10 will bind a run unit to your object IDD and its subroutine, LADAMUS1, will bind a run unit to your source IDD. If you are executing under the central version, then both dictionaries must be defined to and accessible through that CV. If you are executing in local mode, understand that the following will be used and that the proper load library concatenation (or core-image search specification) is very important to ensure that the correct modules are loaded.
If you wish to migrate all entities which have been assigned the migration status of REVIEW, LADAMU12 will perform the necessary impact analysis and attempt to upgrade the migration status to REPLACE. Note that only those entities with a migration status of YES or REPLACE will be migrated.
All entities except records, elements, and panels will be unconditionally upgraded to REPLACE. The following conditions are imposed for those three:
These restrictions have been implemented for philosophical and technical reasons. They enforce standard change control procedures by ensuring that any change is reflected in all affected entities. They also allow the AMU to abide by the builder code restrictions of the CA-IDMS compilers. For example, IDMSDDDL will not permit the replacement of a map owned record, so it is necessary to delete the map(s), replace the record, and then recreate the map(s).
While owning programs (and dialogs) are considered to be prerequisites for the replacement of records, maps, and modules, their inclusion in the migration is not required. The Component Replacement Report will, however, inform you if any of these have been omitted.
It is possible that some prerequisites have been included in the migration and have been assigned the migration status of NO. For example, if you are migrating a dialog which exists in both dictionaries, have updated a process, but have not regenerated the dialog, then the migration status of the process (module) is REVIEW and the migration status of the dialog is NO. When LADAMU12 upgrades the process to REPLACE, it will also upgrade the dialog to REPLACE and inform you of the cause. This should, of course, never occur in a well controlled environment.
If LADAMU12 detects more than 200 prerequisite maps or records have been omitted or cannot be replaced, it assumes that something is grossly wrong with your selection criteria and will abort after listing the 200 entity names. This situation could occur if you have made a change to a globally used entity (such as the element ERROR-STATUS), and are only migrating a single dialog which uses it.
The Replacement Prerequisite Cross Reference (LADAMU11) may be useful in relating entities to their required prerequisites.
Upon completion of LADAMU12, any entities which still have the migration status of REVIEW should be addressed in some fashion. These entities will not be migrated by the AMU.
LADAMU12 updates the EXTRACT and REPLACE files in place. If a rerun is required due to any reason (power failure, I/O error), LADAMU10 must be rerun first.
LADAMU10 may pass the following return codes.
LADAMU12 may pass the following return codes.
Up to six reports may be produced in Phase II. We consider the reports produced by LADAMU10 and LADAMU12 to be the most important output of the AMU. If you do not look at any other listings, please make sure you check, and fully comprehend, the meanings of these reports.
The Migration Component Report (Summary) by Entity (LADAMU10-2) lists all entities which have been selected for possible migration. The report is sequenced alphabetically by entity type and entity name. For each component entity, it lists the name, version, new version where applicable, migration status, and an explanatory message, if appropriate.
The Migration Component Review Report (LADAMU10-1) is identical to the Migration Component Report in sequence and format, but lists only those entities which have been assigned the migration status of REVIEW or ERROR or for some other reason require that a warning message be issued. As many as 5 messages lines will describe the reasons for the specific migration status assignment. The messages may display:
The absence of any message indicates that the specified condition does not exist, or, in the case of comparisons, that no inconsistencies were encountered.
The Component Replacement Prerequisite Report (LADAMU11) cross references entities assigned the migration status of REVIEW with the prerequisite entities required for their replacement. Two different reports are produced, depending upon the sort sequence of REPLACE file. Both reports are sequenced alphabetically by entity type, name, and version. The report by Component lists each entity assigned the migration status of REVIEW with all of the prerequisites required for its replacement. The report by Prerequisite lists each prerequisite entity with all of the REVIEW entities which require it.
Although both of these reports are optional, they may be useful in determining why some entities cannot be replaced (if this turns out to be the case in LADAMU12). The input REPLACE file for these reports should be the file created by LADAMU10 and not updated by LADAMU12. If you wish to run these reports only if you need them, after LADAMU12, make sure that you use the proper file as input.
The Component Replacement Report by Entity (LADAMU12-1), sequenced alphabetically by entity type and name, lists all entities which have been assigned the migration status of REVIEW and the action that is being taken. It also lists all prerequisite entities which have been omitted from the migration. You may see the following messages:
The Updated Component Summary by Entity (LADAMU12-2) is only produced if any entities have had their migration status upgraded to REPLACE. Except that it issues no explanatory messages, it is identical to the Migration Component Report and, essentially, is designed to give you a final updated version.
//jobname JOB site parameters
//step1 EXEC PGM=LADAMU10
//STEPLIB DD DSN=loadlib,DISP=SHR
// DD DSN=idmsload,DISP=SHR
DD statements for the object IDD
DD statements for the source IDD, if COMPARE=FULL or STRUCTURE
//SYSIDMS DD DSN=sysidms,DISP=SHR for DMCL name specification if necessary
//INFILE DD DSN=sorted05,DISP=SHR
//OUTFILE DD DSN=extract10,DISP=(,CATLG,DELETE),UNIT=unit,
// SPACE=space1,DCB=*.INFILE
//REPLACE DD DSN=replace,DISP=(,CATLG,DELETE),UNIT=unit,
// SPACE=space2,DCB=(RECFM=FB,LRECL=90,BLKSIZE=blksz)
//COMPARE DD UNIT=unit,SPACE=space3,
// DCB=(RECFM=FB,LRECL=300,BLKSIZE=blksz)
//REVIEW DD SYSOUT=sysout class
//ENTITY DD SYSOUT=sysout class
/*
//step2 EXEC standard site SORT
include site standard SORT JCL
//SORTIN DD DSN=replace,DISP=SHR
//SORTOUT DD DSN=replS1,DISP=(,CATLG,DELETE),UNIT=unit,
// SPACE=space2,DCB=*.SORTIN
//SYSIN DD *
SORT FIELDS=(1,86,BI,A)
/*
//step3 EXEC PGM=LADAMU11
//STEPLIB DD DSN=loadlib,DISP=SHR
//EXTRACT DD DSN=extract10,DISP=SHR
//REPLACE DD DSN=replS1,DISP=SHR
//SYSLST DD SYSOUT=sysout class
/*
//step4 EXEC standard site SORT
include site standard SORT JCL
//SORTIN DD DSN=replace,DISP=SHR
//SORTOUT DD DSN=replS2,DISP=(,PASS),UNIT=unit,
// SPACE=space2,DCB=*.SORTIN
//SYSIN DD *
SORT FIELDS=(43,39,A,1,47,A),FORMAT=BI
/*
//step5 EXEC PGM=LADAMU11
//STEPLIB DD DSN=loadlib,DISP=SHR
//EXTRACT DD DSN=extract10,DISP=SHR
//REPLACE DD DSN=replS2,DISP=SHR
//SYSLST DD SYSOUT=sysout class
/*
//step6 EXEC PGM=LADAMU12
//STEPLIB DD DSN=loadlib,DISP=SHR
//EXTRACT DD DSN=extract10,DISP=OLD
//REPLACE DD DSN=replS1,DISP=OLD This is the file from step2
//SYSLST DD SYSOUT=sysout class
loadlib Load library containing AMU programs
idmsload Load library containing IDMS modules for the object IDD and for the
source IDD if COMPARE=FULL or STRUCTURE has been specified
space1 The same as that allocated for extract05
space2 Allow for 1 record per prerequisite entity occurrence
space3 Allow for about 3500 records
* $$ JOB JNM=jobname,site parameters
// JOB site parameters
* step 1 - LADAMU10, Place LIBDEFS her
// UPSI 0
// ASSGN SYS005,SYSLST
JCL statements for the object IDD
JCL statements for the source IDD, if COMPARE=FULL or STRUCTURE has been
specified
JCL for SYSIDMS file (if needed for DMCL specification)
// ASSGN SYS030,unit,VOL=volume,SHR
// DLBL INFILE,'extract05',0
// EXTENT SYS030,volume,,,space1
// ASSGN SYS031,unit,VOL=volume,SHR
// DLBL OUTFILE,'extract10',0
// EXTENT SYS031,volume,,,space1
// ASSGN SYS032,unit,VOL=volume,SHR
// DLBL REPLACE,'replace',0
// EXTENT SYS032,volume,,,space2
// ASSGN SYS033,unit,VOL=volume,SHR
// DLBL AMUWRK1,'amuwrk1',0
// EXTENT SYS033,volume,,,space4
// ASSGN SYS035,unit,VOL=volume,SHR
// DLBL COMPARE,'compare',0
// EXTENT SYS035,volume,,,space3
// EXEC LADAMU10,SIZE=768K
/*
* step 2 - SORT ‘replace’ for LADAMU11 & LADAMU12
Execute your standard site SORT. Use 'replace' as SORTIN. Call SORTOUT 'replS1'.
SORT FIELDS=(1,86,BI,A),WORK=work
RECORD TYPE=F,LENGTH=(90)
INPFIL BLKSIZE=3600
OUTFIL BLKSIZE=3600
END
/*
* step 3 - LADAMU11,
Place LIBDEFS her
// ASSGN SYS005,SYSLST
// ASSGN SYS030,unit,VOL=volume,SHR
// DLBL EXTRACT,'extract10',0
// EXTENT SYS030,volume,,,space1
// ASSGN SYS032,unit,VOL=volume,SHR
// DLBL REPLACE,'replS1',0
// EXTENT SYS032,volume,,,space2
// EXEC LADAMU11,SIZE=400K
/*
* step 4 - SORT ‘replace’ for LADAMU11
Execute your standard site SORT. Use 'replace' as SORTIN. Call SORTOUT 'replS2'.
SORT FIELDS=(43,39,BI,A,1,47,BI,A),WORK=work
RECORD TYPE=F,LENGTH=(90)
INPFIL BLKSIZE=3600
OUTFIL BLKSIZE=3600
END
/*
* step 5 - LADAMU11, Place LIBDEFS her
// ASSGN SYS005,SYSLST
// ASSGN SYS030,unit,VOL=volume,SHR
// DLBL EXTRACT,'extract10',0
// EXTENT SYS030,volume,,,space1
// ASSGN SYS032,unit,VOL=volume,SHR
// DLBL REPLACE,'replS2',0
// EXTENT SYS032,volume,,,space2
// EXEC LADAMU11,SIZE=400K
/*
* step 6 - LADAMU12, Place LIBDEFS her
// ASSGN SYS005,SYSLST
// ASSGN SYS030,unit,VOL=volume,SHR
// DLBL EXTRACT,'extract10’,0
// EXTENT SYS030,volume,,,space1
// ASSGN SYS031,unit,VOL=volume,SHR
// DLBL REPLACE,'replS1',0 This is the file from step2
// EXTENT SYS031,volume,,,space2
// EXEC LADAMU12,SIZE=400K
/*
/& * $$ EOJ
space1 The same as that allocated for extract05
space2 Allow for 1 record per prerequisite entity occurrence
space3 Allow for about 1 megabyte
space4 Allow for one 133-byte block for each selected component entity