The descriptions below identify facilities or techniques you can use to identify the individual application components you need to migrate. To extract information on components stored in libraries or other data sets, use an appropriate operating system utility.
IDD DISPLAY Statement
Using either the online or batch dictionary compiler, you can list the names and version numbers of entity occurrences with a simple form of the DISPLAY ALL statement. Any of the IDD entity types can be displayed.
Using an optional WHERE clause on the DISPLAY ALL statement, you can more closely select the occurrences you want displayed. With any entity types, you can qualify the occurrence name. For some entity types, there are additional selection criteria that you can specify, such as the user ID of the person who created the entity.
Note: For more information on the DISPLAY ALL statement and its WHERE clause, see the discussion on entity-occurrence display in CA IDMS IDD DDDL Reference Guide.
Command Facility
With either the online or batch command facility, you can:
IDMSRPTS
IDMSRPTS is a utility that produces reports on information stored in the dictionary. One of its options, the Program Cross-Reference Listing, is particularly useful for migration operations if you are using program registration. The report lists all subschemas for a specified schema and all of the programs registered against those subschemas.
Note: For a sample of this report and instructions on how to run the IDMSRPTS utility, see the CA IDMS Utilities Guide.
DREPORTs
DREPORTs also report on information stored in the dictionary. There are some DREPORTs that summarize information for dictionary entities and some that present detailed information on these entities.
From the summary reports, you can obtain the names and version numbers of the components that need to be migrated. If you need to know whether other related components will be affected, you can run one or more of the reports that present detailed information.
Note: For more information about DREPORTs, see the CA IDMS Reports Guide.
AREPORTs
AREPORTs report on CA ADS dialogs, application structures, and their associated components (such as subschemas, RCMs, maps, and processes) from the information stored in the DDLDML area of the dictionary.
The complete detail report is most useful when you are planning the migration of an entire application. When planning the migration of more than one dialog, run the report that keys in on only the dialogs you need.
Note: For more information about AREPORTs, see the CA IDMS Reports Guide.
SQL Catalog
The SQL catalog contains the definitions of all SQL-defined database entities. It also contains information on all access modules and the tables that they reference (or records, for SQL DML applications that access non-SQL defined databases). Since the catalog is itself an SQL-defined database, SQL SELECT statements may be used to query its contents.
Dictionary Classes and Attributes
Classes and their attributes are primarily a means of extending the documentation capabilities in the dictionary. When migrating, documentation by class and attribute provides a powerful mechanism to analyze and identify the components involved. Using classes and attributes provides you with the capability to display a simple list of names or to report on the details of all components having the same attribute. For example, using the DDDL compiler, you can display all modules associated with attribute TEST within class STATUS:
display attribute test within class status with modules.
Note: For more information about creating classes and attributes and display entities based on class and attribute, see the CA IDMS IDD DDDL Reference Guide. For more information about reporting by class and attribute, see the CA IDMS Reports Guide.
Naming Conventions
Naming conventions help in identifying and migrating components.
Although there are no hard-and-fast rules for designing naming conventions, there are a few factors that you should keep in mind:
Many of the DREPORTs display the components sorted in ascending order by name. If the names of all components of an application begin with the same few characters, it is easy to distinguish one application from another, but more difficult to distinguish components within an application. Likewise, if the names of all elements within a record begin with the same few characters, it is easy to distinguish one record from another in a list, but more difficult to distinguish elements within a record.
The software permits names of different lengths for different components. If you want several characters of every name to identify the application, select a small number (for example, 2 or 3) of characters for this purpose, in order to leave enough characters for other purposes.
Consider selecting a consistent number of characters to identify the record in which an element is placed or components within a particular application. If you choose a standard number of characters and place them in a standard position, it will be easy to sort information or to scan lists or reports for a particular item.
As an alternative to embedding an application identifier in component names, you may choose to use a class/attribute pair. This arrangement allows more characters per name for other purposes, while still providing a connection between components of the same application.
|
Copyright © 2014 CA.
All rights reserved.
|
|