TOC PREV NEXT INDEX DOC LIST MASTER INDEX




Control > Maintenance > Upgrade To New Release (Apex/Summit)

After installation, upgrade your subsystems using the Upgrade to New Release dialog. (Note that if you are performing a patch install, it is not necessary to run apex_upgrade. Installing a patch to an existing release is covered in the Installation Guide.) The Upgrade to New Release dialog performs the following actions:

The functionality of apex_upgrade command is described below, followed by a description of the Upgrade to New Release dialog.

General Information

There are four basic actions that can be done with apex_upgrade:

These actions correspond to the following four options:

-create_model_map <map>
-use_model_map <map>
-revert
-commit

The actions are described below:

Action #1: Create a model map

In the previous versions of apex_upgrade, the set of new models to use was provided by the user on the command line. Models that not specified on the command line were taken from environment variables (eg $APEX_ADA95_MODEL).

This version of apex_upgrade computes the set of new models by translating the version number (eg 3.2.0) in old models to the new version number (eg 4.0.0). A one-to-one mapping of old to new models is created, and stored in a file specified by the user using the "-create_model_map <map>" option. After its creation, you should inspect the newly created <map> file. Each line of this file is of the form "old_model: new_model". If any new_model is set to UNKNOWN, that means apex_upgrade was unable to determine a replacement view. You must either edit this file and replace all instances of UNKNOWN with valid models, or rerun apex_upgrade with the -create_model_map <map> option omitting views based on the old_models that were mapped to UNKNOWN.

You may also edit the <map> file to override any new_model values.

Views that have already been upgraded will have the new models listed in the old_model column of the <map> file. The corresponding new_model will be set to "ALREADY_IS_NEW_MODEL", and can be left as-is.

Action #2: Do the upgrade (using the model map)

You can specify the set of views to be upgraded explicitly, or via subsystem names or configuration files. Specifying a subsystem will upgrade the Policy/Switches file for that subsystem, and all views in the subsystem. Specifying a configuration file will upgrade all views in the configuration.

Views can be removed from the list to be upgraded via the -skip* options. You have the option of running apex_upgrade in two passes. The reason for breaking apex_upgrade into two passes is that some product installations have unix file permissions such that different people must perform pass 1 on different sets of views. If this is not a concern for your installation, you can perform both passes during a single invocation of apex_upgrade. Use the -pass option to specify which pass(es) to perform.

Pass 1 performs the following operations:

Pass 2 performs the following operations:

The reason for breaking apex_upgrade into two passes is that some product installations have unix file permissions such that different people must perform pass 1 on different sets of views. If this is not a concern for your installation, you can perform both passes during a single invocation of apex_upgrade. Use the -pass option to specify which pass(es) to perform.

Action #3: Revert (to pre-upgrade state)

Backing out upgrade

This version of apex_upgrade allows you to partially back out an upgrade. Backups of following information is saved before apex_upgrade alters it.

Running apex_upgrade with the -restore option will restore these files, and remodel views.

Note, however, that once views are cleaned (during pass 1) compilation information cannot be retrieved.

Action #4: Commit (remove files needed to Revert)

Although it will not harm anything to leave the backup files in place, the -commit option will remove them should you wish to do so.

Upgrading very old views

apex_upgrade is designed to upgrade views based on models from Apex beyond a specific version (see -upgrade_very_old_views of usage section at bottom of output for exact Apex version). If you attempt to upgrade views based on older models, apex_upgrade will print an error, and give you the option of re-running with the -upgrade_very_old_views option. It is expected that there will be problems if you use this switch to upgrade old views. But it is provided for advanced Apex users who can finish upgrading views by hand after apex_upgrade has done what it can.

Remodeling views with non-Rational keys

If a C/C++ view has the BUILD_KEY switch set to a value other than $APEX_BASE/c++/keys/* the view is said to have a non-Rational key. The BUILD_KEY will not be updated, and the view will not be remodeled unless the -replace_other_keys switch is specified.

Similarly, if any other view has the COMPILER_KEY switch to a value other than $APEX_BASE/ada/key.ss/*.{rel,wrk} the view is said to have a non-Rational key. The COMPILER_KEY will not be updated, and the view will not be remodeled unless the
-replace_other_keys switch is specified.


Dialog Description

The following is a top-to-bottom description of the Upgrade To New Release dialog.

The "Create Model Map" action must be performed before you can perform the action "Do Upgrade".

Command Line Interface: apex_upgrade.


Rational Software Corporation 
http://www.rational.com
support@rational.com
techpubs@rational.com
Copyright © 1993-2001, Rational Software Corporation. All rights reserved.
TOC PREV NEXT INDEX DOC LIST MASTER INDEX TECHNOTES APEX TIPS