Option | Description |
-debug | Displays debug information. |
-showme | List all processes that would be executed, but do not actually execute any programs or SQL files. |
-needConfig | Displays a list of migrations that are required by a project. |
-listMigrations | Displays a list of migrations needed without applying them. |
PR | Release | Patch | Required | Config Required | Script Exists | ConfigType |
---- | ------- | ----- | -------- | ------ | ------ | ---------- |
19254 | 5.5 | 3 | Y | Y | Y | config_sql |
19831 | 6.0 | 3 | Y | N | Y | schema_sql |
Column | Description |
---|---|
PR | Bug number for the migration. |
Release | Migration release level, two numbers not including the first digit. For example, release 1.8.1 would be just 8.1 in this field. |
Patch | Migration patch level. If the release if 1.8.1.2, then the Patch would be 2. |
Required | Whether or not this migration is required for the system to function properly. If set to Y, all projects would be forced to execute this migration when encountered. A value of N means that the migration is optional, and it would be skipped for any projects that do not list it within their <proj>_config_ready.dat file. |
Config Required | Whether or not configuration is required by a project for the system to function properly. This value is set to Y whenever a change is made that requires configuration work. For instance, if a new required column is added to a configuration table, the population of this new column properly is the domain of the project engineer, not the developer. Setting this field to Y will flag to all project engineers that this migration requires their attention before the migration can be executed. The specific instructions for configuration migration will be documented in the bug’s Migration section; the manual migration text file located in $NMS_HOME/migration/manual. Project engineers signify that the configuration has been examined and completed by adding this migration bug to the <proj>_config_ready.dat file. |
Script Exists | Indicates whether a script exists for the migration. For example, if a script exists for bug 19254, then there is a script pr19254-migration that performs the migration. Not all migrations involve explicit scripts. As an example, a configuration table change would normally not require a migration. However, if it is important that a new configuration column be properly populated, this must be flagged for project engineers. This is done by adding the bug to pr_migration.dat, setting Config Required to Y and Script Exists to N. Even though there is no migration script, the migration process will not proceed until the project engineer has signified that the configuration is complete by adding the bug to the <proj>_config_ready.dat file. |
Config Type | Describes the type of configuration change. Valid values are: • config_sql - A configuration SQL file has changed. • schema_sql - A schema SQL file has changed. • retain_sql - A retain SQL file has changed. • core_sql - A core (required) data SQL file has changed. • data - Model (facilities) data is being migrated. • app_defaults - New or obsolete application default options. • map_rebuild - The migration script will regenerate map files. • metafile_rebuild - The script will regenerate all map metafiles. • service_restart - Services must be restarted. • environment_restart - All user environments must be restarted. • post_setup - migration is run during nms-post-setup |
Warning | Remedy |
---|---|
WARNING THE FOLLOWING MIGRATIONS NEED CONFIGURATION PR_NUMBER RELEASE_PATCH | This warning is displayed when migrations requiring manual changes are found. To determine the necessary changes, refer to the corresponding file in the $NMS_HOME/migration/manual directory. After making the manual changes, add the PR number to the $NMS_CONFIG/migration/<project>_config_ready.dat file. |
DATABASE RELEASE LEVEL IS GREATER THAN SOURCE RELEASE LEVEL MIGRATING BACKWARDS NOT SUPPORTED | This error indicates that the schema level of the database is greater than the runtime executables that are being used. You can return to a prior release if you execute the nms‑setup script with the -clean command line option and perform a model build. You should not return to a prior release without running a nms‑setup -clean and a model build, for there may be unresolved problems that could cause system instability. |