Phase I (LADAMU05), based upon user-supplied selection criteria and options, reads the source IDD and extracts a file containing information about all component entities. One EXTRACT record is written for each entity occurrence which is encountered. For example, if five selected dialogs use the same RECORD, five EXTRACT records will be written for the RECORD as well as for each of its ELEMENTS.
The determination of component entities is generally based upon DDLDML set relationships. If these relationships have been broken, entities will not be selected. For example, if you delete a subschema, its relation to dialogs (programs) is not defined unless you regenerate the dialogs, or use IDMSDDDL syntax to relate them. When any entity is deleted, all set connections are deleted and are not automatically re-established when the entity is added. Even without regard to the AMU, it would be wise to have a standard that requires the use of MODIFY or REPLACE syntax for changes (where feasible).
Seven types of input statements allow you to tailor the migration to your particular needs.
If SRCDICT is specified, it must be first in the input stream (as the BIND RUN UNIT is executed after reading the first record). Selection Criteria statements should follow all other types of input statements. At least one Selection Criteria statement is required. Other than that, any combination of input statements, in any order, is permitted. All input begins in position 1 of the input record. Parameters are separated by commas; any specifications following the first blank are ignored. There are no continuations; use multiple input statements if necessary.
Dictionary Definition statements are required only if your source or object IDD is a secondary dictionary (i.e. one which requires DBNAME table translation). They also permit execution of the AMU when you are migrating to a remote site.
SRCDICT=dictname [,NODE=nodename]
dictname specifies the DBNAME of the source dictionary. It is used as part of the
BIND RUN UNIT in Phase I and, also, as part of the SIGNON or DBNAME syntax for
the CA-IDMS compilers in Phase IV.
nodename specifies the node for DDS sites.
OBJDICT=dictname [,NODE=nodename]
dictname specifies the DBNAME of the object dictionary. It is used as part of the
BIND RUN UNIT in Phase II and, also, as part of the SIGNON or DBNAME syntax for
the CA-IDMS compilers in Phase V.
nodename specifies the node for DDS sites.
OBJICT=NONE
may be used to migrate to a remote IDD which, you are certain, contains none of the
exported entities. If this specification is made, Phase II does not read the object
IDD, but simply assigns each entity a migration status of YES, causing Phase III to
create ADD syntax for all entities. After the execution of Phase IV, all Phase V files
could be offloaded to tape for transport. Note that if any of the exported entities
reside in the remote IDD, the entities will be modified or the updates will be ignored
depending upon the compiler and the compiler options (see Phase III).
Subschema Change statements may be used to change subschema names, schema names, and/or schema versions during the migration. They do not cause the selection of any subschemas; they merely cause changes to any subschemas selected due to the specification of SUBSCHEMA= or SUBMASK= or because of their relationship to a selected dialog, program, or schema. The changes will be reflected in dialog load modules, IDMSDDDL PROGRAM statements for dialogs and programs, subschema compiler syntax, and subschema load modules (if OPTIONS=SLOAD=COPY has been specified). If you simply want to relate dialogs and programs to a different subschema and not actually migrate the existing subschema to a new name, specify OPTIONS=SUBS=NO in Phase I or do not execute IDMSUBSC in Phase V. If subschemas are actually being migrated to new names (OPTIONS=SUBS=YES), Phase II comparisons are performed against the new name in the object IDD.
Do not specify OPTIONS=SUBS=BYP; if you do, the AMU will not relate any program or dialog to any subschema. Remember, changes will only be made to dialogs and programs that the AMU relates to the subschema, i.e. when there is a DDLDML set relationship between the dialog/program and the subschema. You can check this by issuing a DISPLAY PROGRAM in IDMSDDDL. If it displays a "SUBSCHEMA IS" line, then the relationship does exist.
OLDSS=oldss,oldsc,oldsv,NEWSS=newss,newsc,newsv
oldss specifies the subschema name to be changed
oldsc specifies the owning schema of oldss.
oldsv specifies the version of oldsc.
newss specifies the new subschema name.
newsc specifies the owning schema of newss.
newsv specifies the version of newsc.
A maximum of 50 Subschema Change statements may be included in an execution of the AMU. All parameters are positional and must be included. For any of the old parameters, asterisks (*) may be used to mask to selection. For any of the new parameters, asterisks (*) may be used to indicate same as the old. See input examples #5 and #6 in this chapter for a better understanding.
Variable Name statements define the names of data fields used in process code to hold a dictionary message ID (for a DISPLAY MSG CODE command), a message prefix, or a dialog name (for an inter-dialog control command). When the AMU is parsing process code, it will save any values moved to these fields and process them in the appropriate manner. Note that if OPTIONS=PARSEMOD=NO is specified, the AMU does not parse process code and these specifications are meaningless. A maximum of 3 of each type of statement may be specified.
MSGFIELD=data-name
any 6 position numeric (literal or constant) or 8 position quoted literal (including
prefix) which is MOVEd to data-name will be treated as a dictionary message ID. Note that
CA applications standardly issue messages in this manner.
MPRFIELD=data-name
any literal which is MOVEd to data-name will be used as the prefix for all 6
position dictionary message IDs captured due to a MSGFIELD specification. This prefix
will be used until the end of the process in which it appears or until it is superceded.
If MPRFIELD is not specified, the dialog default message prefix will be used.
IDCFIELD=data-name
any literal which is Moved to data-name will be treated as an imbedded dialog. The
Imbedded Dialog Report will display MOVE as its inter-dialog control command.
Bypass statements specify the names of records, dialogs, programs, modules, maps, subschemas, tables, messages, and elements which you want the AMU to bypass. A maximum of 15 of each type of Bypass statement may be specified. The intended use of each is stated below. Improper use of these statements may result in the failure of dialog generation/program compilation in the object IDD, or unexpected results in dialog/program execution.
BYPREC=record-name
record-name specifies the name of the record to be bypassed. Neither the record
nor any of its elements will be selected for migration. It is possible, however, that
some of its elements may be selected because of their participation in another selected
record. This is intended for instances where you intentionally have different record
structures on the source and object dictionaries, and you are certain that
the differences will have no impact on those entities being migrated. For example, you
have just installed a CA-IDMS maintenance tape in your test environment and they have
changed the ADSO-STAT-DEF-REC to include a new condition name for one of the elements.
You are not ready to implement the maintenance level in production, but you must migrate
some dialogs which, of course, copy the record, but don't reference the new condition name.
BYPPRO=program-name
program-name specifies the name of the program or dialog to be bypassed. Neither
the program/dialog nor any of its component entities will be selected for migration. The
intended use is to exclude specific programs/dialogs when selecting by ADSA application
or dialog/program mask.
BYPMOD=module-name
module-name specifies the name of the module to be bypassed. The intended use is
to exclude specific module(s) when selecting by MODMASK.
BYPMAP=map-name
map-name specifies the name of the map to be bypassed. Neither the map nor its
panel nor any of its records will be selected for migration. The intended use is to
exclude specific map(s) when selecting by MAPMASK.
BYPSUB=subschema-name
subschema-name specifies the name of the subschema to be bypassed. The intended
use is to exclude specific subschema(s) when selecting by SUBMASK.
BYPTAB=table-name
table-name specifies the name of the edit/code table to be bypassed.
BYPMSG=msg-id
msg-id specifies the 8 position (including prefix) id of the message to be
bypassed. The intended use is to exclude specific message(s) when selecting by MESSAGE
range.
BYPELE=element-name
element-name specifies the name of the element to be bypassed. The intended use is
only for environments which are so screwed up that they must use it.
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 to select standardly.
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. See input example #7 in this chapter for a situation where this might be useful.
For ease of use, we will divide Options statements into 4 categories.
Entity selection options allow you to select or bypass specified entity types or a specified group of entity occurrences. You may specify any or all of the following:
OPTIONS=CLASSATTR= YES <--
FILES= NO
USERS= BYP
SUBS=
UDCS=
UDNS=
CLASSATTR applies to CLASSES and ATTRIBUTES.
FILES applies to FILES.
USERS applies to USERS.
SUBS applies to SUBSCHEMAS.
UDCS applies to USER DEFINED COMMENTS.
UDNS applies to USER DEFINED NESTS.
YES specifies that you wish to select occurrences of the specified entity
type for possible migration.
NO specifies that you do not wish to migrate occurrences of the specified
entity type, but you would like them to appear in any reports.
BYP specifies that you wish to completely bypass occurrences of the specified
entity type.
If NO or BYP is specified for any entity types, then, in addition to not migrating
occurrences of those entity types, the Phase III default will be set to PUNCH WITHOUT
entity type. See Phase III Options Statements for further details.
OPTIONS=PARSEMOD= YES <--
NO
YES specifies to parse all process code to extract included modules, called
dialogs/programs, and dictionary message IDs. Included modules and dictionary
message IDs will be selected for possible migration. Called dialogs/programs will
be captured only for the Imbedded Dialog Report. This option has a minimal impact
upon the execution time of Phase I.
NO specifies to not parse any process code. Note that if included modules are not
selected for migration, the results of dialog generation in the object
IDD are unpredictable.
OPTIONS=DBRECS=BYP
specifies to bypass selection of all schema owned records and their associated
elements. The elements, of course, may be selected due to their participation in
another selected record. This should be used if you are certain that there have been
no changes to schema records and you do not wish to have these records included in the
reporting features of LADAMU20 or LADAMU25. If this option is not specified, then
schema owned records will be selected for possible migration.
OPTIONS=DIRL=BYP
specifies to bypass selection of all records and elements created by the CA-IDMS
directory load. This should be used if IDMSDIRL has been executed against the object
IDD. If this option is not specified, then entities created by IDMSDIRL will be
selected for possible migration.
OPTIONS=ELEMENTS= NORMAL <--
BYP
EXPLODE
NORMAL specifies to select all ELEMENTS that participate in selected records.
BYP specifies to bypass all ELEMENTS. This is intended to be used by those who wish
to migrate records using COBOL syntax. If you specify this option, then the
Phase III OPTIONS=RECORDS will default to COBOL. See Phase III Options statements
for further details.
EXPLODE specifies to "explode" all ELEMENTS. Elements are standardly selected based
upon their participation in the record element list of a selected record. If the
element structure (INQ-058) is consistent with the record element structure
(SDR-042), then all subordinate elements will also be selected due to their
participation in the same record element list. If, however, the element and record
element structures are inconsistent, then it is possible for the AMU to migrate a
group element without all of its subordinates. For example, group element ABC
consists of subordinate elements A, B, & C. Element ABC is added to record REC1,
so now REC1 has elements ABC, A, B, & C. Now, element ABC is modified so that its
subordinate elements are A, B, & D (instead of C). Due to ignorance, incompetence,
or laziness, element ABC is not replaced in record REC1. When the AMU selects REC1,
it selects elements ABC, A, B, & C. When IDMSDDDL attempts to add element ABC to the
object IDD, it cannot find subordinate element D. Specification of this
option will cause the AMU to "explode" each element, i.e. walk its subordinate
element chain. This may severely degrade the performance of Phase I. Each element
will be selected one time because of its participation in the record element list
and one time for each level of subordination. For example, an "07 level" element
would be selected as a subordinate of the "01 level", of the "03 level", of the
"05 level" and for its own record element. At a quick glance, there is a fourfold
increase in the required processing, but add in the intermediate junction records
and it is worse than that. Use this option only if absolutely necessary.
OPTIONS=CASE= UPPER <--
UPLOW
UPPER indicates that all process commands are coded in upper case and no special
action is required when parsing.
UPLOW indicates that process commands may be coded in lower case. Note that this
will cause LADAMU05 to convert all process code to upper case prior to parsing
and may have some performance impact. It should, therefore, only be used if
really applicable.
Load module options are used to specify whether you wish to copy load modules from the source to the object IDD, or whether you wish to regenerate them in the object IDD. Your specification has no bearing on the migration of source code type entities, such as records, elements, modules, map source, or table source.
If you copy load modules, you are assured that execution using the object IDD will be identical to execution using the source IDD. However, if you ever must regenerate from the source code, you have no guarantee that it will be successful (i.e. if source code and load modules were not synchronized in the source IDD, they will not be synchronized in the object IDD).
If you generate load modules, you are assured that the source code and load module will be synchronized, but you have no guarantee that execution will be as it was tested using the source IDD (i.e. whether or not source code and load modules were synchronized in the source IDD, they will be in the object IDD). It is even possible that the generation of the load modules will fail during the migration, if untested source code changes were never generated in the source IDD.
OPTIONS=LOAD= GENERATE <--
DLOAD= COPY
MLOAD= NO
SLOAD=
TLOAD=
LOAD sets the specified value for all 4 load modules types. Additionally,
LOAD=COPY sets ALOAD=COPY (see Miscellaneous Options).
DLOAD applies to DIALOGS.
MLOAD applies to MAPS.
SLOAD applies to SUBSCHEMAS.
TLOAD applies to TABLES.
GENERATE specifies to create CA-IDMS compiler syntax to generate the specified
load module type. Note that for dialogs, in addition to creating ADSOBCOM syntax,
Phase III will create a PUNCH LOAD MODULE so that ADSOBCOM can retrieve the names
of the component entities.
COPY specifies to create IDMSDDDL syntax to PUNCH LOAD MODULE for the specified
load module type.
NO specifies to neither copy nor generate load modules in the object IDD.
This might be used if your load modules reside in a load or core-image library
instead of the source DDLDCLOD area, and you intend to use that library or
copy them to a different load or core-image library associated with your object
IDD.
In order to keep map and dialog load modules synchronized with regard to time/date stamps, you should use the same specification for MLOAD and DLOAD.
Entity comparison options specify the rules for comparing entities to determine the migration status in Phase II. See Phase II Entity Comparisons for additional information.
OPTIONS=COMPARE= STANDARD <--
ELECOMPR= REVIEW
MAPCOMPR= REVIEWEQ
MODCOMPR= FULL
MSGCOMPR= STRUCTURE
PROCOMPR=
RECCOMPR=
TABCOMPR=
COMPARE applies to all entity types and, additionally, sets each xxxCOMPR option to the specified value.
ELECOMPR applies to ELEMENTS.
MAPCOMPR applies to MAPS.
MODCOMPR applies to MODULES (excluding TABLES, but including QFILES and culprit reports).
MSGCOMPR applies to MESSAGES.
PROCOMPR applies to PROGRAMS (including dialogs).
RECCOMPR applies to RECORDS.
TABCOMPR applies to TABLES (actually stored as MODULES).
STANDARD, REVIEW, REVIEWEQ, FULL, STRUCTURE see details in Phase II Entity Comparisons.
Be sure to read the special considerations when specifying FULL or STRUCTURE. Note that
REVIEWEQ is only valid with OPTIONS=COMPARE=.
The miscellaneous options are, simply put, those that do not fit into any other category.
OPTIONS=ALOAD= COPY <--
ONLY
NO
COPY specifies that if the ADSA selection criteria is used, ADSA definitions
should be selected for possible migration also. The ADSA definition consists of a
PUNCH LOAD MODULE and a PUNCH PROGRAM for the ADSA application. Note that this
option is set if LOAD=COPY is specified.
ONLY specifies that if the ADSA selection criteria is used, only the ADSA
definition should be selected for possible migration. The component entities
(programs, dialogs, and their components) of the application will not be selected.
NO specifies that if the ADSA selection criteria is used, only the component
entities (programs, dialogs, and their components) of the application should be
selected for possible migration. The ADSA definition will not be migrated.
OPTIONS=DUPS= RETAIN <--
DROP
RETAIN specifies that duplicate entity occurrences should be retained in the
EXTRACT file in order to execute LADAMU20 or LADAMU25.
DROP from the EXTRACT file by LADAMU10. Additionally, if this is specified,
Phase I will only select a given record occurrence (and its elements) the first
time it is encountered. This could significantly improve the performance of
Phase I, especially in a large migration where several records are used by many
of the dialogs. The use of this option will prohibit the execution of
LADAMU20 and LADAMU25; do not specify it if you intend to execute either of
those reports.
OPTIONS=REPELEM= ONLY <--
EVEN
ONLY specifies that LADAMU12 should upgrade the migration status of ELEMENTS to
REPLACE only if all prerequisite records have been included in the migration.
EVEN specifies that LADAMU12 should upgrade the migration status of all
ELEMENTS to REPLACE even if some prerequisite records are not included in the
migration. Note that this will certainly cause elements and record elements to
not be synchronized in the object IDD when the migration is complete. It
is intended for use when you intentionally do not want the element to be replaced
in one or two records. This might be the case if you are creating new versions of
records and will delete the old version after the migration is complete.
OPTIONS=SRCRELS= 12 <--
OBJRELS= 10
SRCRELS specifies the release of IDMS which accesses the source IDD.
OBJRELS specifies the release of IDMS which accesses the object IDD.
12 specifies IDMS release 12.0 or later.
10 specifies IDMS release 10.x.
Print statements may be used to alter characteristics of the AMU reports. The specifications will be reflected in all AMU reports. Currently, the only type is LPP.
LPP=lines-per-page-n
lines-per-page-n is a value from 1 to 98 which represents the number of lines to be
printed on each page of each report. The default of 58 lends itself nicely to the standard
print density of 6 lines per inch.
Selection Criteria statements specify the entity occurrence at which the selection process begins. It is recommended that you specify the highest level possible. If you are migrating an entire system created using ADSA, then specify the ADSA application name. If you have not used ADSA, but employ some reasonable naming convention, you can probably specify some combination of dialog names/masks and program names/masks. The lower level selection criteria (MAP, MODULE, RECORD) are primarily intended for the migration of partially developed applications.
The component entities of each selection criteria are depicted in figure 6 and are also specified within the description of its syntax. However, to avoid redundancy, only the highest level component entities are specified. You may, in turn, find each of their component entities within the description of their syntax. For example, the component entities of an ADSA application are programs and dialogs. This implies that the component entities are actually programs and dialogs and the component entities of those programs and dialogs, such as maps, modules, records, elements, etc. Remember that some of the specified component entities may or may not be selected due to the specification of various options.
For all entities, users, classes, attributes, user defined comments, user defined nests, and user defined entities are considered component entities, and will or will not be selected depending upon the options specified.
S e l e c t i o n C r i t e r i a
Component DIALOG PROGRAM MODULE MAP RECORD USER
Entity DMASK PMASK SCHEMA MODMASK MAPMASK RECMASK ATTRIBUTE
Edit/Code Table X X X X X
Edit Module X X X X
Element X X X X X X
Map X X X X
Map Message ID X X X X
Module X X X X
Included Module¹ X X X
Module Message ID¹X X X
Program X X X
Record X X X X X X
Subschema¹ X X X X
The following entities will be selected for each of the above components.
Attribute¹ X X X X X X X
Class¹ X X X X X X X
User¹ X X X X X X X
User Defined Comment¹ X X X X X X X
User Defined Entity¹ X X X X X X X
User Defined Nest¹ X X X X X X X
Figure 6. Definition of component entities
1. Optionally selected based upon Phase I options.
All entities will be "exploded" as necessary.
Most of the selection criteria statements allow the specification of the following two fields:
VERSION=version-n specifies the entity version to be selected. If this is omitted, it will always default to 1. VERSION=ALL may be specified for any MASK selection criteria. Other special considerations for this parameter may be found under the ADSA= selection criteria. NEWVER=newver-n specifies the new version to be assigned to all selected applications, dialogs, tables, maps and panels during the migration. If this parameter is omitted, it will default to the existing version of the entity, i.e. the version will not be changed. While the intent of this parameter is to allow for the use of DCUF TEST in the source IDD and then migrate to version 1 in the object IDD, this may also be used to create a new version of an existing dialog or application (using a single dictionary as both the source and object IDDs). Note that the new versions will be created only for entities which can be loaded from DDLDCLOD (with the exception of panels, which are included solely to maintain consistency with the map). Note, also, that all Phase II comparisons will be performed against the new version in the object IDD.
For all mask specifications (DMASK, PMASK, MAPMASK, MODMASK, RECMASK), all dictionary occurrences of the entity type are matched against the mask (character by character, left to right). An asterisk (*) may be used in the mask to match any character.
The various selection criteria statements are:
ADSA=name [,VERSION=version-n][,NEWVER=newver-n]
Specifies the ADSA application name to be selected. All dialogs, programs, and global records that are defined to the application, and all of their component entities will also be selected, unless OPTIONS=ALOAD=ONLY has been specified. Subroutine dialogs and programs which are called within the application, but are not defined to the application will not be selected. To select these dialogs and programs, use some combination of DIALOG, DMASK, PROGRAM, and PMASK statements.
If VERSION= is specified, then the specified version of the application and of each
dialog and program will be selected, if that version exists. If the specified version does
not exist, version 1 will be selected. This fully mimics the rules in effect during
DCUF TEST.
If this is the first time you are migrating a specific application definition, be aware
that the AMU does not update the task application table. You will have to execute
ADSOTATU to perform this function.
DIALOG=name [,VERSION=version-n][,NEWVER=newver-n]
The specified DIALOG and its subschema, map, modules, and records will be selected.
DMASK=mask[,VERSION=version-n/ALL] [,NEWVER=newver-n]
All DIALOGS which match the mask (and version), and their components, will be selected.
PROGRAM=name [,VERSION=version-n][,NEWVER=newver-n]
The specified conventional PROGRAM and its subschema, maps, modules, and records will be
selected.
PMASK=mask[,VERSION=version-n/ALL] [,NEWVER=newver-n]
All conventional PROGRAMS which match the mask (and version), and their components,
will be selected.
MAP=name [,VERSION=version-n][,NEWVER=newver-n]
The specified MAP and its panel, records, tables, edit modules, help text modules, and
dictionary messages will be selected. This is intended to be used for stand-alone maps
or for partially developed applications.
MAPMASK=mask[,VERSION=version-n/ALL] [,NEWVER=newver-n]
All MAPS which match the mask (and version), and their components, will be selected. This
is also intended to be used for stand-alone maps or for partially developed applications.
MODULE=name [,VERSION=version-n][,LANGUAGE=language]
The specified MODULE and its included modules and dictionary messages will be selected.
LANGUAGE may be specified to clarify the selection; if omitted, the first module with the
specified name and version will be selected. This is intended to be used for QFILES,
culprit reports, TABLES loaded by online programs, and partially developed applications.
MODMASK=mask[,VERSION=version-n/ALL][,LANGUAGE=language]
All MODULES which match the mask (and version and language), and their components, will
be selected. This is also intended to be used for QFILES, culprit reports, TABLES loaded
by online programs, and partially developed applications.
RECORD=name[,VERSION=version-n]
The specified RECORD and its elements will be selected. This is intended to be used for
partially developed applications.
RECMASK=mask[,VERSION=version-n/ALL]
All RECORDS which match the mask (and version), and their elements, will be selected.
This is intended to be used for partially developed applications. This criteria is
prohibited if you have specified OPTIONS=SRCRELS=57 (indicating you are executing under
IDMS release 5.7).
SCHEMA=name[,VERSION=version-n]
All records, elements, and subschemas of the specified SCHEMA will be selected. The AMU
does not migrate the SCHEMA. Note that if you specify OPTIONS=SUBS=BYP, only the schema
records and elements will be selected. Conversely, if you specify OPTIONS=DBRECS=BYP,
only the subschemas will be selected.
SUBSCHEMA=name[,SCHEMA=sname,VERSION=sversion-n]
Only the specified subschema will be selected. The owning schema name (and version) is
only necessary if the subschema name is not unique.
SUBMASK=mask[,SCHEMA=sname,VERSION=sversion-n]
All SUBSCHEMAS which match the mask will be selected. The owning schema name/version may
be specified to further qualify the selection.
USER=name
All entities related to the specified USER, and all of their component entities, will be
selected. However, the USER, itself, will only be selected if it is actually related to
some other entity and OPTIONS=USERS=YES has been specified (or defaulted). This is
intended to be used for partially developed applications or for the migration of
documentational entities. If you choose to use this for standard migrations, it is
recommended that you only attach the USER to the highest level entities.
USER=ALL [,SYSTEM=dcsystem-n]
If the optional parameter SYSTEM is not specified, all USERS in the source IDD
will be selected. Only the USERS and their ATTRIBUTES and nested USERS will be selected.
No other related entities will be selected. This is intended to be used for the migration
of USERS and their passwords only.
SYSTEM=dcsystem-n specifies the 1-4 character numeric system ID of a DCSYSTEM created
using the sysgen compiler. If this is specified, all USERS in the specified system in the
source IDD will be selected. Only the USERS and their ATTRIBUTES and nested USERS
will be selected. No other related entities will be selected. This is intended to be used
for the migration of USERS and their passwords only.
ATTRIBUTE=name[,CLASS=class]
All entities related to the specified ATTRIBUTE, and all of their component entities,
will be selected. However, the ATTRIBUTE, itself, will only be selected if it is actually
related to some other entity and OPTIONS=CLASSATTR=YES has been specified (or defaulted).
This is intended to be used for partially developed applications or for the migration of
documentational entities. If you choose to use this for standard migrations, it is
recommended that you only attach the ATTRIBUTE to the highest level entities.
The option parameter CLASS= may be specified to qualify the selection, if you have
duplicate ATTRIBUTE names in your dictionaries.
MESSAGE=message-id[,end-range]
message-id specifies the 8 position message ID (including prefix) to be selected.
end-range need only be specified if you wish to migrate a range of message IDs,
and specifies the 6 position numeric message ID of the last message to be selected. The
AMU will attempt to select all message IDs that fall within the range from message-id to
end-range.
Example # 1: Migrating an Application SRCDICT=TEST2 OPTIONS=CLASSATTR=NO,USERS=NO,UDCS=NO ADSA=APPL2 DIALOG=EDITDATE DIALOG=CONVDATE MODMASK=AP2,LANGUAGE=OLQ In this example, we are migrating from a secondary dictionary, whose DBNAME is TEST2, to a primary dictionary, which may reside on the same machine or on a different machine. We have used CLASS/ATTRIBUTE structures, USER relationships, and USER DEFINED COMMENTS to track the development cycle, but we do not wish to migrate those structures to the new dictionary. We would, however, like to have them included in the Component Listing by Dialog (LADAMU20). We have developed our application using ADSA and have called it APPL2. We are going to migrate all programs and dialogs which are defined to APPL2, as well as its definition. We use 2 subroutine dialogs (EDITDATE and CONVDATE) which are not defined to the application. We have also created some QFILES, whose names all begin with characters AP2, and wish to migrate them also. Note that if we forgot to specify either of the subroutine dialogs, the Imbedded Dialog (LADAMU07) would inform us of that, and we could restart Phase I, including them in the selection criteria, or we could migrate them in a second execution of the AMU. Example # 2: Creating New Versions SRCDICT=TEST OBJDICT=TEST OPTIONS=CLASSATTR=BYP,SUBS=BYP,USERS=BYP,UDCS=BYP,UDNS=BYP OPTIONS=DIRL=BYP,DBRECS=BYP,DUPS=DROP,PARSEMOD=NO,ELEMENTS=BYP OPTIONS=FILES=BYP DMASK=D12345,NEWVER=32 In this example, we are creating a new version, in the same dictionary, of all dialogs whose names begin with the characters D12345. A new version (32) of all maps, panels and tables used by these dialogs will also be created. Note, however, that the new versions of the dialogs will reference the old versions of any processes, records, and elements. Since we are not actually migrating anything, we have specified the options to bypass most of the extraneous processing. Example # 3: Migrating an Application OPTIONS=DBRECS=BYP,SUBS=BYP,DUPS=DROP BYPREC=ADSO-STAT-DEF-REC MSGFIELD=MESSAGE-ID MSGFIELD=MESSAGE-ID2 DMASK=D123 DMASK=****DATE PROGRAM=ISSUEMSG PMASK=P123 In this example, we are migrating between primary dictionaries. The DBA staff has already made whatever schema/subschema changes may have been necessary in the object IDD, so, for efficiency, we will bypass the selection of subschemas and schema records. Since we do not intend to execute LADAMU20 or LADAMU25, we will drop duplicate records from the EXTRACT file, also for efficiency and to save some DASD space. We know that there is a slight difference in the ADSO-STAT-DEF-REC between the two dictionaries, but we do not wish to migrate it and it will not impact the execution of our appplication. Our application dialogs standardly call a subroutine to issue dictionary messages; the data fields MESSAGE-ID and MESSAGE-ID2 are passed to the subroutine. We want to ensure that all message IDs are selected for possible migration. Our application is comprised of all dialogs whose names begin with the characters D123, all dialogs whose 8-character names end with DATE, all programs whose names begin with P123, and the program ISSUEMSG. Example # 4: Migrating Schema Records SRCDICT=TEST OBJDICT=PROD OPTIONS=DIRL=BYP,SUBS=BYP,COMPARE=STRUCTURE SCHEMA=MYSCHEM In this example, we are migrating from a secondary dictionary, whose DBNAME is TEST, to another secondary dictionary, whose DBNAME is PROD and may reside on the same machine or on a different machine. We only wish to migrate the records and elements of schema MYSCHEM; we do not want to migrate any its subschemas at this time. IDMSDIRL has been executed against the PROD dictionary, so we will bypass those entities. As this migration is part of a change cycle, most of the records and elements already exist in the PROD dictionary, and we want the AMU to perform a complete structural comparison to determine if anything has changed. Example # 5: Migrating Schema Records and Subschemas SRCDICT=PHILA OBJDICT=NONE OPTIONS=DIRL=BYP OLDSS=PH******,PHSCHEM,2,NEWSS=NY******,NYSCHEM,1 SCHEMA=PHSCHEM,VERSION=2 In this example, we have distributed databases around the world and we are migrating from a secondary dictionary, whose DBNAME is PHILA, to a remote dictionary, which, for our purposes, is in New York. The schema for the New York database (NYSCHEM) is identical to the schema for the Philadelphia database (PHSCHEM), with the exception of the page ranges. The AMU will create ADD syntax for all schema records and elements (except IDMSDIRL entities) and for all subschemas of schema PHSCHEM version 2. It will change the subschema compiler syntax so that the first two characters of the subschema names will be changed from PH to NY and the WITHIN SCHEMA line will be changed from PHSCHEM VERSION 2 to NYSCHEM VERSION 1. After Phase IV is completed, the Phase V files will be offloaded to tape and shipped to New York (along with the schema source for NYSCHEM version 1). As you have already surmised, we must make the name changes because, as a standard DP shop, we will not consider installing CA-IDMS release 12 until support for the release we are currently using is discontinued. Example # 6: Relating Programs to Different Subschemas SRCDICT=TEST OBJDICT=PROD OPTIONS=SUBS=NO,DBRECS=BYP OLDSS=*,TESTSCHM,*,NEWSS=********,PRODSCHM,* OLDSS=*,TES2SCHM,*,NEWSS=********,PRO2SCHM,1 DMASK=*,VERSION=ALL In this example, we are migrating all dialogs in a secondary dictionary named TEST to another secondary dictionary named PROD. We will not migrate subschemas or schema records. All dialogs which used any subschema of schema TESTSCHM (any version) in TEST will be modified to use the same named subschema of schema PRODSCHM (the same version) in PROD. Similarly, all dialogs which used any subschema of schema TES2SCHM (any version) in TEST will be modified to use the same named subschema of schema PRO2SCHM (version 1) in PROD. Example # 7: Forcing the Migration of Unchanged Entities SRCDICT=PROD OBJDICT=TEST OPTIONS=COMPARE=REVIEW,ELECOMPR=STRUCTURE,RECCOMPR=STRUCTURE DIALOG=DIALOG1 In this example, dialog DIALOG1, and all of its components, except elements and records, will be replaced in the TEST dictionary. Elements and records will only be replaced if they are structurally inconsistent (and if all prerequisites are included in the migration as specified in Phase II Replacement of Modified Entities).
LADAMU05 may pass the following return codes:
LADAMU07 may pass the following return codes:
The Input Control Listing (LADAMU05) 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. For ADSA= or any mask specifications, the report lists each top level entity which has been selected.
The Imbedded Dialog Report (LADAMU07) lists all dialogs and programs which are imbedded within (or called from) process code (i.e. which are the object of an inter-dialog control command) and which have not been included in the selection criteria statements. Its intent is to warn you that you may have accidentally omitted some dialogs which you should be migrating. For each dialog or program, it lists the calling module, the inter-dalog control command, and its entity type (DIALOG or PROGRAM). Note that this is not a cross reference of called dialogs. It only lists the first occurrence (alphabetically by calling module name) of any missing dialog or program.
//jobname JOB site parameters //step1 EXEC PGM=LADAMU05 //STEPLIB DD DSN=loadlib,DISP=SHR // DD DSN=idmsload,DISP=SHR //ddldml DD DSN=ddldml,DISP=SHR //ddldcmsg DD DSN=ddldcmsg,DISP=SHR //ddldclod DD DSN=ddldclod,DISP=SHR //sysjrnl DD DUMMY //SYSIDMS DD DSN=sysidms,DISP=SHR for DMCL name specification if necessary //EXTRACT DD DSN=extract05,DISP=(,CATLG,DELETE),UNIT=unit, // SPACE=space1,DCB=(RECFM=FB,LRECL=250,BLKSIZE=blksz) //IMBED DD DSN=imbed,DISP=(,CATLG,DELETE),UNIT=unit, // SPACE=space2,DCB=(RECFM=FB,LRECL=50,BLKSIZE=blksz) //SYSLST DD SYSOUT=sysout class //CARDIN DD * input statements here /* //step2 EXEC standard site SORT include site standard SORT JCL //SORTIN DD DSN=extract05,DISP=SHR //SORTOUT DD DSN=sorted05,DISP=(,CATLG,DELETE),UNIT=unit, // SPACE=space1,DCB=*.SORTIN //SYSIN DD * SORT FIELDS=(1,51,A,174,67,A,172,2,D),FORMAT=BI /* //step3 EXEC standard site SORT include site standard SORT JCL //SORTIN DD DSN=imbed,DISP=SHR //SORTOUT DD DSN=srtdimbd,DISP=(,PASS),UNIT=unit, // SPACE=space2,DCB=*.SORTIN //SYSIN DD * SORT FIELDS=(1,50,BI,A) /* //step4 EXEC PGM=LADAMU07 //STEPLIB DD DSN=loadlib,DISP=SHR //EXTRACT DD DSN=sorted05,DISP=SHR //IMBED DD DSN=srtdimbd,DISP=(OLD,DELETE) //SYSLST DD SYSOUT=sysout class // loadlib Load library containing LADAMU05 idmsload Load library containing IDMS modules for the source IDD space1 Allow for approximately 100-300 records per dialog/program space2 Allow for 1 record per imbedded dialog occurrence blksz Specify an appropriate block size for unit ddldml ddldcmsg DDNAMES and dataset names for the source IDD, ddldclod as specified in the appropriate DMCL sysjrnl
* $$ JOB JNM=jobname,site parameters // JOB site parameters * step1 - LADAMU05,Place LIBDEFS here // UPSI 0 // ASSGN SYS005,SYSLST // ASSGN SYS006,SYSRDR // ASSGN SYS030,DISK,VOL=volume,SHR // DLBL EXTRACT,'extract05',0 // EXTENT SYS030,volume,,,space1 // ASSGN SYS031,DISK,VOL=volume,SHR // DLBL IMBED,'imbed',0 // EXTENT SYS031,volume,,,space2 JCL for the source IDD here - Include DDLDML, DDLDCMSG, DDLDCLOD, SYSJRNL all as specified in the appropriate DMCL JCL for SYSIDMS file (if needed for DMCL specification) // EXEC LADAMU05,SIZE=640K Input statements here /* * step 2 - SORT 'extract05' Execute your standard site SORT using 'extract05' as SORTIN. Call SORTOUT sorted05' SORT FIELDS=(1,51,BI,A,174,67,BI,A,172,2,BI,D),WORK=work RECORD TYPE=F,LENGTH=(250) INPFIL BLKSIZE=3500 OUTFIL BLKSIZE=3500 END /* * step3 - SORT 'imbed' for LADAMU07 Execute your standard site SORT using 'imbed' as SORTIN and SORTOUT SORT FIELDS=(1,50,BI,A),WORK=work RECORD TYPE=F,LENGTH=(50) INPFIL BLKSIZE=3500 OUTFIL BLKSIZE=3500 END /* * step4 - LADAMU07, Place LIBDEFS here // ASSGN SYS005,SYSLST // ASSGN SYS030,DISK,VOL=volume,SHR // DLBL EXTRACT,'sorted05',0 // EXTENT SYS030,volume,,,space1 // ASSGN SYS031,DISK,VOL=volume,SHR // DLBL IMBED,'imbed',0 // EXTENT SYS031,volume,,,space2 // EXEC LADAMU07,SIZE=256K /* /& * $$ EOJ space1 Allow for approximately 100-300 records per dialog/program space2 Allow for 1 record per imbedded dialog occurrence work Appropriate number of SORT WORK files for your environment