This chapter presents an overview of the Apex and Summit installation to provide context for the installation procedures from "Installation Quick Start".
The following topics are covered in this section:
The following table lists, in order, the major steps in the Apex and Summit installation. Estimates of the time required for each major step are also provided. Your actual time will vary with factors such as your experience level, your workstation load, and your network performance.
|
Step
|
Estimated Time
|
|---|---|
|
Read the release note for any instruction updates not available at the printing time of this manual.
|
20 minutes
|
|
Ensure that your workstations satisfy the requirements described in "Prerequisites". Your system administrator may need to perform some of the requirements.
|
5 minutes per workstation to verify that requirements are satisfied; more time if they are not
|
|
Load the release media as described in "Installation Quick Start".
|
30 minutes
|
|
Configure your system as described in "Installation Quick Start" and "Configuring Apex and Summit". Estimated installation and configuration time is dependent on the need for licensing and whether you need to call Rational for license keys.
|
10 - 60 minutes
|
This installation guide refers to the Apex and Summit version numbers as x.y.z where x is a major release, y is a minor update, and z is a fix release. Please substitute the current version number where ever you see x.y.z.
Apex or Summit can be installed on a stand-alone workstation or a client-server network that includes many workstations.
Conceptually, you can have different workstations performing each of these roles:
Stores the installation and user data (for example, subsystems and Ada programs). When a file server is distinct from other workstations, its file systems must be:
Runs Apex and Summit processes such as check-out, editing and check-in. When a compute server is distinct from a client, the compute server is accessed via remote login (rlogin) or remote shell (rsh) from the client.
Most commonly, a file server doubles as the license server, and clients double as their own compute servers. In the simplest configuration, a stand-alone workstation performs all roles.
If you are installing Apex or Summit on a client-server network, note that you must enter specific commands on specific workstations. For example, the license server daemon must be started on the license server, not on another workstation.
The Apex and Summit releases are structured as follows:
rational_dir/
apex - Symlink to current release
base/ - Base subsystems and models
ada/ - Ada subsystems
model.ss/
platform.x.y.z.rel/
other_subsystems.ss/
platform.x.y.z.rel/
keys/
c++/ - C/C++ subsystems and models
model.ss/
platform.x.y.z.rel/
compilers/
keys/
cots/ - Commercial off-the-shelf software
task/ - Summit/TM subsystems
task_kinds.ss/ & task_domain_prototype.ss/
config/ - Data for installed products
releases/
apex.x.y.z/ - Apex/Summit release directory
install/ - Installation scripts
platform/ - Platform-dependent files
bin/
lib/
other_dirs/ - Platform-independent files
Note above that base is not nested under apex., (where apex. is the current version of Apex or Summit you are installing) because the base subsystems and models are expected to endure longer than individual releases such as apex..
Apex and Summit users will use the model views in model.ss to create their own subsystem views. Apex Ada users will compile and link their programs with the predefined Ada packages in lrm.ss and predefined.ss. It might not be convenient for them to recompile and relink their programs exactly when you install a new Apex Ada release.
Since Apex has program libraries that get installed in the base directory it is required that all of your code use this common base directory. Failure to do this results in unnecessary recompilation in a multiple-copy Apex installation.
If for performance reasons, you want to install Apex on multiple machines, you must at the minimum have a single base directory.
If this suggestion is not followed and users attempt to code units from different machines which mount different base directories (even with the same mount point), the compiler will detect differences in time stamps which will trigger complete recompilation of the entire closure of the unit.
Plan to structure your rational_dir as follows, where apex.i.j.k and apex.m.n.o are imagined future releases:
rational_dir/
base/
releases/
apex./
apex.i.j.k/
apex.m.n.o/
apex
In the future this structure will allow you, for example, to easily remove apex. without disturbing old portions of base on which some users might still depend. You might even find it convenient to place apex., apex.i.j.k, apex.m.n.o, and base in separate file systems that are mounted under rational_dir and rational_dir/releases.
Set rational_dir/apex, a symbolic link, to the current Apex release-for example: releases/apex.. Then Apex and Summit users can reference rational_dir/apex instead of rational_dir/releases/apex.. Eventually, when you have installed and tested apex.i.j.k, you can update the symbolic link to switch your users to the new release without requiring any further action on their part.
The Storage-Location menu in the ./install program can be used to guide you in selecting alternate storage directories in the case where you do not have sufficient disk space to install Apex or Summit. When running the install program, keep selecting option `t' until you reach the Storage-Location Menu. You can enter `h' to get help for this menu.
No additional setup is required once installation is complete. However, optional setup instructions are available for individual users in the Getting Started Guide.
If you are upgrading from a previous Apex or Summit release, individual users should read "Upgrading from Previous Releases" in the Release Note.