The components to be migrated should include not only what needs to be migrated but also what is affected by the migration. The descriptions that follow identify components typically involved in migration and how these affect other components.
CA ADS Application Structure
The application structure is saved as a load module in the DDLDCLOD area of the data dictionary; no source definitions for the application are stored in the DDLDML area. The application structure is relatively autonomous. If you make changes to the application structure, you do not need to recompile any other application components.
Changes to the application structure, however, can logically affect other components, specifically dialogs. For example, if you change a response name, you will want to change the response field value of any response processes you expect to execute before control is passed to the response. The application will execute without modifying the dialog, but it will not produce the expected results.
Maps
Changes to maps fall into two categories:
Critical changes update the date/time stamp. Any dialogs that use the map must be recompiled before they can be executed. Critical changes to maps include:
Noncritical changes to maps do not cause the map date/time stamp to be updated and, therefore, do not affect any other application components.
Dialogs
Dialogs associate subschemas or access modules, maps, and process code. The dialog load module contains executable process source code. Recompiling a dialog containing SQL statements creates a new relational command module (RCM). Any access modules that include that RCM must then be recompiled also. Recompiling a dialog does not affect any other application component.
Process Source Code
Process source code is stored in the data dictionary. Process code is compiled by the dialog compiler and becomes executable when the dialog is compiled. To have changes to process source code reflected in the dialog load module, you must recompile the dialog.
RCMs (SQL DML Applications Only)
If a program/dialog containing SQL statements is recompiled, an RCM is automatically created for it and stored as a load module in the DDLDCLOD area. If the program/dialog load module is copied intact to the production system, the RCM load module must also be copied.
Subschemas (Navigational DML Applications Only)
If you change a subschema associated with a dialog, map, or program, you do not need to recompile the dialog, map or program. If the subschema changes cause you to change the logic of a process module, you will need to recompile the dialog(s) in which the module is used. If the subschema changes affect the lengths of data elements or records or the procedural code in a program, you will need to recompile and relink the program.
Access Modules (SQL DML Applications Only)
Access modules must be compiled from scratch using the catalog that defines the database to be accessed. They cannot be copied in load module form like other application components. A typical migration would copy the RCM load modules, apply any needed database definition changes and then create all access modules used by the application, using the CREATE ACCESS MODULE command.
Non-SQL Data Definitions
Non-SQL data is defined in records that consist of record elements. Records are either database records, which are included in a schema, or work records, which are defined through the DDDL compiler.
Changes to database records require that all subschemas that use those records be recompiled. All SQL access modules that reference those records must also be recompiled for SQL applications that access non-SQL defined databases. Changes to either database records or work records may require map and/or dialog recompilation.
Some changes to database records require some form of restructuring to incorporate those changes into the existing database.
Note: For more information about modifying the schema definition of a non-SQL defined database, see Chapter 33, “Modifying Schema Entities".
SQL Data Definitions
Data is defined in tables that consist of columns. Changes to these tables require that all access modules that use those tables be recreated. Depending on the definition of a particular access module, this recreation may occur automatically or may have to be initiated manually. These changes may require map and dialog recompilation.
Some changes to table definitions require some form of restructuring to incorporate those changes into the existing database.
Note: For more information about modifying the schema definition of an SQL defined database, see Chapter 30, “Modifying Schema, View, Table, and Routine Definitions".
Adaptive Query Management
Adaptive query management is a feature of the IDMS SQL option that automatically recompiles access modules in response to certain kinds of changes in a database application. For example, if a dialog/program has been recompiled, the runtime SQL engine detects whether corresponding access modules have been recompiled to include the new RCM. If not, it automatically recompiles the access module at runtime (if the AUTO RECREATE ON option was specified when the access module was created or last altered). Adaptive query management applies to SQL DML applications that access either non-SQL or SQL-defined databases.
Adaptive query management also automatically recompiles existing access modules that access SQL-defined databases when the definitions of those databases change. Note that this does not happen for non-SQL defined databases. It is the responsibility of the applications administrator to manually recompile any access modules affected by changes to a non-SQL defined database.
Edit and Code Tables
Changes to stand-alone edit and code tables that are associated with a map require that the map be recompiled only if the tables are linked to the map. Changes to unlinked tables do not affect the map load module.
Examples
Example 1──Adding a Data Item to a Screen
Suppose users of an application request an additional data item on a screen. To determine what is affected, consider the relationship between the map and the new data item:
For an application using navigation DML, you need to do the following if the data item is from a database record already being used by the map:
To take these actions, you need to migrate the map and the dialogs.
For an application using navigation DML, you need to do the following if the database record is part of the subschema used by the map, but the record is not already in use by the map:
To take these actions, you need to migrate the map and the dialogs.
For an application using navigation DML, you need to do the following if the database record is not already part of the subschema:
To take these actions, you need to migrate the subschema, map, and dialogs.
If the data item can be derived (for example, calculated) from data already available to the application, you need to:
To take these actions, you need to migrate the record, subschema, map, affected processes, and dialogs.
If the application uses SQL DML, a work record will already have been defined to move data between the map and the SQL statements in the dialog. To add another database item to the screen, you need to:
Example 2──Implementing a New Application
Suppose you implement an entirely new application based on an existing database. When the new application has been adequately tested, all of the application components need to be migrated from the test system to the production system. In addition, you must also consider what database components to migrate:
|
Copyright © 2014 CA.
All rights reserved.
|
|