Phase III (LADAMU15) reads the updated EXTRACT file to create CA-IDMS compiler syntax to migrate only those entities assigned the migration status of YES or REPLACE. In all, 15 files of syntax are created. All files named PHASE4- are input to Phase IV; those named PHASE5- are input to Phase V. See figures 7 & 8 for file descriptions and syntax formats.
The replacement of modified subschemas, maps and panels will cause the creation of DELETE and ADD syntax. The replacement of all other entities will cause the creation of REPLACE syntax (unless OPTIONS=REPLVERB=MOD is specified).
The migration of entities assigned the migration status of YES will, of course, cause the creation of ADD syntax.
Three types of input statements allow you to modify the formats of the generated CA-IDMS compiler syntax.
All input begins in position 1 of the input record. Parameters are separated by commas; any specifications following the first blank are ignored. Precisely one SRCUSER and one OBJUSER statement is required. All other input is optional.
File Name Types of Syntax Generated
PHASE4-DDDL1 SIGNON; SET OPTIONS FOR SESSION
PUNCH statements for CLASS, ATTRIBUTE, USER, ELEMENT,
RECORD, TABLE, MESSAGE, MODULE, and LOAD MODULE
PHASE4-DDDL2 SIGNON; SET OPTIONS FOR SESSION
PUNCH statements for PROGRAM (including dialogs), MAP,
and PANEL
PHASE4-UBSC SIGNON; SET OPTIONS FOR SESSION
PUNCH SUBSCHEMA
PHASE4-MPUT PROCESS=DECOMPILE (or TERSE)
MAP=
PHASE5-DDDL1 SIGNON; SET OPTIONS FOR SESSION
MOD ENTITY statements for UDCS and UDNS
MODIFY RECORD REMOVE ALL for all records being replaced
PHASE5-DDDL3 MOD TABLE GENERATE
PHASE5-DDDL5 SIGNON; SET OPTIONS FOR SESSION
PHASE5-UBSC1 SIGNON; SET OPTIONS FOR SESSION
PHASE5-UBSC3 MOD SUBSCHEMA GENERATE
PHASE5-MAP1D SIGNON; DELETE MAP statements for maps being replaced
PHASE5-MAP1A SIGNON
PHASE5-MPUT PROCESS=LOAD
MAP=
PHASE5-BGEN SIGNON
GENERATE FROM LOAD DIALOG= or
GENERATE FROM SOURCE DIALOG=
PHASE4-SYSIDMS DBNAME=; user supplied statements
PHASE5-SYSIDMS DBNAME=; user supplied statements
Figure 7. Description of Phase III output files
File Name Default Syntax Formats
PHASE4-DDDL1 SET OPTIONS FOR SESSION INPUT COLUMNS ARE 1 THRU 80
EOF IS OFF registration OVERRIDE QUOTE IS quote
DEFAULT IS ON list DELETE IS OFF
DISPLAY WITHOUT AREAS DESTINATIONS LINES
LOGICAL-TERMINALS PANELS PHYSICAL-TERMINALS
QUEUES SETS SYSTEMS SUBSCHEMAS TASKS SAME AS
LRS WITHIN SYSTEM WHERE USED
attributes users udcs udns files AS SYNTAX.
PUNCH entity name VERSION IS version VERB verb.¹
PUNCH ATTRIBUTE name WITHIN CLASS classname VERB verb
WITHOUT ELEMENTS MODULES MAPS RECORDS
ENTRY POINTS PROGRAMS.
PUNCH CLASS name VERB verb WITHOUT ATTRIBUTES.
PUNCH RECORD name VERSION IS version VERB verb
WITH RECELEMS DET COM DEF CUL OLQ SYN
attributes users udn udc files.²
PUNCH USER name VERB verb WITHOUT ELEMENTS MAPS
PROGRAMS RECORDS.
PHASE4-DDDL2 The same specifications as PHASE4-DDDL1 except that the
DISPLAY WITHOUT does not include SUBSCHEMAS
PHASE4-UBSC SET OPTIONS FOR SESSION INPUT COLUMNS ARE 1 THRU 80
EOF IS OFF registration OVERRIDE QUOTE IS quote
DEFAULT IS ON list DISPLAY AS SYNTAX.
PHASE5-DDDL1 SET OPTIONS FOR SESSION INPUT COLUMNS ARE 1 THRU 80
& EOF IS OFF registration OVERRIDE QUOTE IS quote
PHASE5-DDDL5 DEFAULT IS ON list DELETE IS OFF.
PHASE5-UBSC1 SET OPTIONS FOR SESSION INPUT COLUMNS ARE 1 THRU 80
EOF IS OFF registration OVERRIDE QUOTE IS quote
DEFAULT IS ON list.
Figure 8. Default Syntax Formats
Italicized items are variable depending upon options, site defaults, and IDMS release.
1. This is for all entities unless specified otherwise.
2. This is only if OPTIONS=RECORDS=COBOL has been specified or defaulted.
SRCUSER=user[,PASSWORD=password]
OBJUSER=user[,PASSWORD=password]
user specifies the name of a user with ALL authority in the appropriate IDD, and
will be used as part of the various signon statements for the CA-IDMS compilers in
Phase IV (SRCUSER) and Phase V (OBJUSER). Precisely one SRCUSER and one OBJUSER
statement are required.
password must be supplied if the specified user has been assigned a password.
Note that neither the user name nor password may contain imbedded blanks, and that the AMU does not validate the user name or password. Any errors will be detected by the CA-IDMS compilers in Phases IV or V.
Options statements may be used to tailor the various types of CA-IDMS compiler syntax which is generated.
Multiple options statements may be specified in one input record. Simply separate each option with a comma. See the input examples in this chapter for a better understanding.
All options have a default value and only need to be specified if you wish to change that value. In the listed syntax, an arrow points to the default. In the 2 instances where no arrow exists, the default is determined by a Phase I option, as clarified in the syntax explanation.
The options table is updated in the order in which the options are input. If you specify the same option twice, the second one will overlay the first one.
You may specify any or all of the following:
OPTIONS=CLASSATTR= YES
USERS= NO
UDCS=
UDNS=
CLASSATTR applies to ATTRIBUTES.
USERS applies to USERS.
UDCS applies to USER DEFINED COMMENTS.
UDNS applies to USER DEFINED NESTS.
YES specifies that you wish to migrate entities WITH their relationships to
the specified entity type. This is the default if YES was specified for the
corresponding Phase I option.
NO specifies that you wish to migrate entities WITHOUT their relationships
to the specified entity type. This is the default if NO or BYP was specified
for the corresponding Phase I option.
These four options specify whether you wish to migrate entities with or without their relationships to attributes, users, user defined comments, and user defined nests. The generated syntax is part of the SET OPTIONS statement in PHASE4-DDDL1 and PHASE4-DDDL2. If the corresponding Phase I option was specified as YES, then the default for Phase III will be YES (PUNCH WITH). If the corresponding Phase I option was specified as NO or BYP, then the default for Phase III will be NO (PUNCH WITHOUT).
If you extensively employ these four entity types for documentational purposes and you standardly define them to all dictionaries at the same time and you wish to migrate these relationships to your object IDD and you do not intend to use the reporting features of LADAMU20 and LADAMU25, then you may see a significant performance improvement in Phase I and a significant reduction in the size of the EXTRACT file if you specify BYP in Phase I and specify YES in Phase III.
Note that these specifications are meaningless if the Punch Format statements PH4OPT1 or PH4OPT2 are specified.
OPTIONS=RECORDS= IDD
COBOL
IDD specifies that records are to be punched using standard IDD syntax. This is
the default unless OPTIONS=ELEMENTS=BYP was specified in Phase I.
COBOL specifies that records are to be punched using COBOL syntax (WITH RECELEM).
This is the default only if OPTIONS=ELEMENTS=BYP was specified in Phase I.
Note that this specification is meaningless if the Punch Format statement
RECPNCH is specified.
OPTIONS=UPDREADY= SHARED <--
PROTECTED
SHARED specifies to READY DDLDML for shared update in the Phase V IDMSDDDL and
IDMSUBSC steps.
PROTECTED specifies to READY DDLDML for protected update in the Phase V IDMSDDDL
and IDMSUBSC steps. This is recommended if you can afford to "lock out" other
updates to your object IDD during the migration as IDMS will not keep
record locks and you may see a significant performance improvement in these steps.
OPTIONS=REPLVERB= REPLACE <--
MOD
REPLACE specifies to use the verb REPLACE in IDMSDDDL when replacing modified
entities.
MOD specifies to use the verb MOD in IDMSDDDL when replacing modified entities.
This may be useful if you maintain relationships in your object IDD which
do not exist in your source IDD. Note, however, that the use of this
option may cause problems. For example, if the initial value of an element has
changed, REPLACE will replace the element and its initial value while MOD will
not replace the old initial value, but will simply add the new initial value,
yielding an element with two initial values.
OPTIONS=REPLOAD= ADD <--
REPLACE
MOD
ADD specifies to use the verb ADD in IDMSDDDL when replacing load modules.
REPLACE specifies to use the verb REPLACE in IDMSDDDL when replacing load modules.
Note that this may not be supported by IDMSDDDL.
MOD specifies to use the verb MOD in IDMSDDDL when replacing load modules.
OPTIONS=DIAGTAB= SAME <--
YES
NO
SAME specifies to use ADSOBCOM GENERATE FROM LOAD syntax to regenerate dialogs.
This should be used unless you need to explicitly turn on or off the generation of
the diagnostic or symbol tables.
YES specifies to use ADSOBCOM GENERATE FROM SOURCE syntax to regenerate dialogs,
specifying DIAGNOSTIC TABLE IS YES.
NO specifies to use ADSOBCOM GENERATE FROM SOURCE syntax to regenerate dialogs,
specifying DIAGNOSTIC TABLE IS NO. This may be useful if you wish to turn off the
diagnostic table generation when migrating from test to production.
This specification is meaningless unless OPTIONS=DLOAD=GENERATE was specified or
defaulted in Phase I.
OPTIONS=SYMBTAB= SAME <--
YES
NO
SAME specifies to use ADSOBCOM GENERATE FROM LOAD syntax to regenerate dialogs.
This should be used unless you need to explicitly turn on or off the generation of
the diagnostic or symbol tables.
YES specifies to use ADSOBCOM GENERATE FROM SOURCE syntax to regenerate dialogs,
specifying SYMBOL TABLE IS YES.
NO specifies to use ADSOBCOM GENERATE FROM SOURCE syntax to regenerate dialogs,
specifying SYMBOL TABLE IS NO. This may be useful if you wish to turn off the symbol
table generation when migrating from test to production.
OPTIONS=MAPS= DECOMPILE <--
TERSE
DECOMPILE specifies to use PROCESS=DECOMPILE syntax to migrate maps.
TERSE specifies to use PROCESS=TERSE syntax to migrate maps.
OPTIONS=MAPDATE= NEW <--
OLD
NEW specifies that maps will be decompiled standardly during migration
OLD specifies to use DATETIME=YES in RHDCMPUT syntax to decompile maps. This is
probably desired if you specified OPTIONS=LOAD=COPY in Phase I.
OPTIONS=COMMIT= NO <--
YES
YES causes the AMU to issue COMMITs in the IDMSDDDL updates in Phase V. A module named AMU-COMMIT-MODULE must exist in the source IDD and must have as its module source just one statement - COMMIT. Syntax will be created to PUNCH MODULE AMU-COMMIT-MODULE WITH MODULE SOURCE ONLY after every 50 PUNCH statements in PHASE4-DDDL1.
OPTIONS=PH4PRT1= LIST <--
PH4PRT2= NOLIST
PH4PRTS=
PH5PRT1=
PH5PRT5=
PH5PRTS=
PH4PRT1 applies to Phase IV step 1 (IDMSDDDL).
PH4PRT2 applies to Phase IV step 2 (IDMSDDDL).
PH4PRTS applies to Phase IV step 3 (IDMSUBSC).
PH5PRT1 applies to Phase V step 4 (IDMSDDDL).
PH5PRT5 applies to Phase V step 12 (IDMSDDDL).
PH5PRTS applies to Phase V step 6 (IDMSUBSC).
LIST specifies to use LIST as part of the SET OPTIONS statement.
NOLIST specifies to use NO LIST as part of the SET OPTIONS statement.
These specifications are meaningless if the corresponding Punch Format statement
PHnOPTx is specified.
Punch Format statements may be used to specify the precise CA-IDMS compiler syntax which you would like to have generated.
A maximum of 10 of each statement type, for each file, is permitted. The generated syntax will replicate positions 9 through 80 of the input record(s) and will appear in the identical sequence. These specifications will completely replace the default syntax formats, as defined in figure 16.
PH4OPT1= your syntax
PH4OPT2=
PH4OPTS=
PH5OPT1=
PH5OPT5=
PH5OPTS=
PH4OPT1 applies to PHASE4-DDDL1.
PH4OPT2 applies to PHASE4-DDDL2.
PH4OPTS applies to PHASE4-UBSC.
PH5OPT1 applies to PHASE5-DDDL1.
PH5OPT5 applies to PHASE5-DDDL5.
PH5OPTS applies to PHASE5-UBSC
your syntax should be the precise syntax you would like to use for the SET OPTIONS
statement in the appropriate file. Your specifications should include
INPUT COLUMNS ARE 1 THRU 80 and REGISTRATION OVERRIDE if any entities have any sort of
user security. Don't forget to end the last statement with a period.
ELEPNCH= your syntax
RECPNCH=
MODPNCH=
PROPNCH=
BGENSYN=
ELEPNCH applies to PUNCH ELEMENT statements.
RECPNCH applies to PUNCH RECORD statements.
MODPNCH applies to PUNCH MODULE statements.
PROPNCH applies to PUNCH PROGRAM statements.
your syntax should be the precise syntax you would like to use for the appropriate
PUNCH statements in PHASE4-DDDL1 and PHASE4-DDDL2. Your specifications will be preceded
by PUNCH entity entity-name VERSION IS version VERB verb. Don't forget to end the last
statement with a period.
BGENSYN applies to ADSOBCOM input statements. Your specifications will be preceded
by GENERATE FROM SOURCE DIALOG IS dialog VERSION IS version
SYSIDMS Specification Statements allow you to create SYSIDMS files for use in Phases IV & V. DBNAME statements will automatically be created if SRCDICT= or OBJDICT= was specified in Phase I; this facility allows you to append other statements. You may, of course, simply create your own files, or (for OS sites) concatenate the created DBNAME= syntax to your own file.
SRCSYSI= your syntax
OBJSYSI=
SRCSYSI applies to the SYSIDMS file for your source IDD (used in Phase IV).
OBJSYSI applies to the SYSIDMS file for your object IDD (used in Phase V).
your syntax should be the precise syntax you would use to build the appropriate
SYSIDMS file. It will be preceded by DBNAME=dictname if you specified SRCDICT=
or OBJDICT= in Phase I.
The Input Error Listing(LADAMU15-1) displays all of your input statements and the action that the AMU has taken. It also informs you of any syntax errors or processing errors which may have been encountered.
The Compiler Input Report (LADAMU15-2) lists total counts for each type of syntax created. This should equal the sum of all entities assigned the migration status of YES and REPLACE, as listed in the Phase II reports.
Example # 1: Using Options Statements SRCUSER=BILL,PASSWORD=CLINTON OBJUSER=LOVESDEM,PASSWORD=FRIES OPTIONS=CLASSATTR=YES,UDNS=YES,UDCS=YES In Phase I, we had specified BYP for each of these corresponding options because we always define these entities to all dictionaries at the same time, and there is no need to migrate them. We are overriding those options in Phase III so that relational data will be included in the PUNCH statements. Example # 2: Using Options Statements SRCUSER=DBA1,PASSWORD=DBPASS1 OBJUSER=DBA2 OPTIONS=MAPS=TERSE,PH4PRT1=NOLIST,PH4PRT2=NOLIST OPTIONS=PH4PRTS=NOLIST,PH5PRT1=NOLIST,PH5PRT5=NOLIST OPTIONS=PH5PRTS=NOLIST,DIAGTAB=NO,SYMBTAB=NO In this example, we are minimizing the printed output that will be produced by the CA-IDMS compilers and, in the regeneration of dialogs, we are eliminating the diagnostic and symbol tables because all dialogs have been thoroughly tested and could not possibly have any problem. The OBJUSER password is not present because user DBA2 has not been assigned a password. Example # 3: Using Punch Format Statements SRCUSER=DONCHU,PASSWORD=MISS OBJUSER=JOHN,PASSWORD=CULLINAN PH4OPTS=SET OPTIONS FOR SESSION INPUT COLUMNS ARE 1 THRU 80 PH4OPTS=EOF IS OFF REGISTRATION OVERRIDE QUOTE IS ' LIST PH4OPTS=DISPLAY WITHOUT HISTORY COMMENTS AS SYNTAX. PROPNCH=WITH NONE AS COMMENTS. In this example, we are changing the SET OPTIONS for PHASE4-UBSC so that history and comments will be excluded from all PUNCH SUBSCHEMA output. We have also chosen not to migrate any PROGRAM statements and are eliminating them by punching them AS COMMENTS. Example # 4: Using Punch Format Statements SRCUSER=CA,PASSWORD=MIGRATOR OBJUSER=PIECEOF,PASSWORD=GARBAGE OPTIONS=UPDREADY=PROTECTED ELEPNCH=WITHOUT SYNONYMS. RECPNCH=WITHOUT SUB EL. In this example, we want to PUNCH elements without synonyms because we have many extraneous element synonyms in our source IDD. Additionally, we will PUNCH records without subordinate elements in order to limit the amount of punched and printed output. We can do this because we don't use picture overrides and we fully comprehend all of the implications.
LADAMU15 may pass the following return codes:
//jobname JOB site parameters //step1 EXEC standard site SORT include site standard SORT JCL //SORTIN DD DSN=extract10,DISP=SHR //SORTOUT DD DSN=sorted10,DISP=(,CATLG,DELETE),UNIT=unit, // SPACE=space1,DCB=*.SORTIN //SYSIN DD * SORT FIELDS=(156,3,A,172,2,D,1,48,A),FORMAT=BI /* //step2 EXEC PGM=LADAMU15 //STEPLIB DD DSN=loadlib,DISP=SHR //INFILE DD DSN=sorted10,DISP=SHR //P4DDDL1 DD DSN=ph4dddl1,DISP=(,CATLG,DELETE),UNIT=unit, // SPACE=space2,DCB=(RECFM=FB,LRECL=80,BLKSIZE=blksz) //P4DDDL2 DD DSN=ph4dddl2 same JCL parameters as ph4dddl1 //P4UBSC DD DSN=ph4ubsc same JCL parameters as ph4dddl1 //P4MPUT DD DSN=ph4mput same JCL parameters as ph4dddl1 //P5MAP1D DD DSN=ph5map1d same JCL parameters as ph4dddl1 //P5DDDL1 DD DSN=ph5dddl1 same JCL parameters as ph4dddl1 //P5DDDL3 DD DSN=ph5dddl3 same JCL parameters as ph4dddl1 //P5DDDL5 DD DSN=ph5dddl5 same JCL parameters as ph4dddl1 //P5UBSC1 DD DSN=ph5ubsc1 same JCL parameters as ph4dddl1 //P5UBSC3 DD DSN=ph5ubsc3 same JCL parameters as ph4dddl1 //P5MAP1A DD DSN=ph5map1a same JCL parameters as ph4dddl1 //P5MPUT DD DSN=ph5mput same JCL parameters as ph4dddl1 //P5BGEN DD DSN=ph5bgen same JCL parameters as ph4dddl1 //P4SYSI DD DSN=ph4sysi same JCL parameters as ph4dddl1 //P5SYSI DD DAN=ph5sysi same JCL parameters as ph4dddl1 //SYSLST DD SYSOUT=sysout class //CARDIN DD * input statements here /* // loadlib Load library containing LADAMU15 space1 The same as that allocated for extract10 space2 Allow for 4 records per entity occurrence blksz Specify an appropriate block size for unit
$$ JOB JNM=jobname,site parameters // JOB site parameters * step 1 - SORT 'extract10' Execute your standard site SORT using 'extract10' as SORTIN. Call SORTOUT 'sorted10' SORT FIELDS=(156,3,BI,A,172,2,BI,D,1,48,BI,A),WORK=work RECORD TYPE=F,LENGTH=(250) INPFIL BLKSIZE=3500 OUTFIL BLKSIZE=3500 END /* * step2 - LADAMU15, Place LIBDEFS here // ASSGN SYS005,SYSLST // ASSGN SYS006,SYSRDR // ASSGN SYS030,DISK,VOL=volume,SHR // DLBL INFILE,'sorted10',0 // EXTENT SYS030,volume,,,space1 // ASSGN SYS031,DISK,VOL=volume,SHR // DLBL P4DDDL1,'ph4dddl1',0 // EXTENT SYS031,volume,,,space2 // ASSGN SYS032,DISK,VOL=volume,SHR // DLBL P4DDDL2,'ph4dddl2',0 // EXTENT SYS032,volume,,,space3 // ASSGN SYS033,DISK,VOL=volume,SHR // DLBL P5MAP1D,'ph5map1d',0 // EXTENT SYS033,volume,,,space3 // ASSGN SYS034,DISK,VOL=volume,SHR // DLBL P4MPUT,'ph4mput',0 // EXTENT SYS034,volume,,,space3 // ASSGN SYS035,DISK,VOL=volume,SHR // DLBL P4UBSC,'ph4ubsc',0 // EXTENT SYS035,volume,,,space3 // ASSGN SYS036,DISK,VOL=volume,SHR // DLBL P5DDDL1,'ph5dddl1',0 // EXTENT SYS036,volume,,,space3 // ASSGN SYS037,DISK,VOL=volume,SHR // DLBL P5DDDL3,'ph5dddl3',0 // EXTENT SYS037,volume,,,space3 // ASSGN SYS038,DISK,VOL=volume,SHR // DLBL P5DDDL5,'ph5dddl5',0 // EXTENT SYS038,volume,,,space3 // ASSGN SYS039,DISK,VOL=volume,SHR // DLBL P5MAP1A,'ph5map1a',0 // EXTENT SYS039,volume,,,space3 // ASSGN SYS040,DISK,VOL=volume,SHR // DLBL P5MPUT,'ph5mput',0 // EXTENT SYS040,volume,,,space3 // ASSGN SYS041,DISK,VOL=volume,SHR // DLBL P5UBSC1,'ph5ubsc1',0 // EXTENT SYS041,volume,,,space3 // ASSGN SYS042,DISK,VOL=volume,SHR // DLBL P5UBSC3,'ph5ubsc3',0 // EXTENT SYS042,volume,,,space3 // ASSGN SYS043,DISK,VOL=volume,SHR // DLBL P5BGEN,'ph5bgen',0 // EXTENT SYS043,volume,,,space3 // ASSGN SYS044,DISK,VOL=volume,SHR // DLBL P4SYSI,'ph4sysi',0 // EXTENT SYS044,volume,,,space3 // ASSGN SYS045,DISK,VOL=volume,SHR // DLBL P5SYSI,'ph5sysi',0 // EXTENT SYS045,volume,,,space3 // EXEC LADAMU15 Input statements here /* /& * $$ EOJ space1 The same as that allocated for extract10 space2 Allow for 4 records per entity occurrence space3 Allocate 1 or 2 tracks work Appropriate number of SORT WORK files for your environment