1 – Project Libraries
There are many ways you can organize the SCA libraries for your
project. Usually, there is one library (or set of libraries)
for the whole project. Each developer has a personal library
containing modules that they have changed but have not yet made
available to the entire project. However, if there is only one
developer working on the project, it makes more sense to use a
single SCA library.
There are many ways you can organize your project libraries. You
can have one project SCA library if it is a reasonable size. You
can use several libraries, one for each subsystem. You may want to
organize your SCA libraries the way your development environment
is organized. For example, have one SCA library for each CMS
library. If your project is divided into different subsystems,
you may want one SCA library for each subsystem.
For information on creating your own SCA library, see the help
topic Building_An_SCA_Library.
Examples of Typical Libraries
Consider a project with three developers: Paul, Mark, and Joanna.
The project consists of two different subsystems, each with its own
SCA library.
Each of the developers also has a personal SCA library in their personal
directories.
Paul, Mark and Joanna set up their SCA libraries using the SCA library
command as follows:
SCA> SET LIBRARY personal_lib,subsystem_1_lib,subsystem_2_lib
When Paul changes a module in Subsystem 1, he compiles it and loads it
into his personal library. For Paul, this hides the old version of the
module in the project library for Subsystem 1, so his SCA library is up
to date and consistent with his changes.
Mark and Joanna do not see Paul's changes in their SCA libraries
because they the SCA library that Paul updated is not in their library
list. They still see the old version of the module in the project
library for Subsystem 1.
Once Paul has completed his change, the nightly build updates everything
for Subsystem 1, replacing the module in the project library. Now Mark
and Joanna can both see the change.
2 – Virtual Libraries
SCA can use more than one SCA library at the same time when doing
queries using the FIND and INSPECT commands. The list of SCA
libraries used for this is called a virtual library. The order
of SCA libraries in the library list is important. A module in
the first library in the library list will hide the same module
in other libraries, further on in the library list. For example,
suppose PROJECT_LIB has modules A, B, C and library MYLIB has
modules A, and D. You can set the library as follows:
LSE Command> SET LIBRARY MYLIB,PROJECT_LIB
The modules visible in the virtual library would be A (from
MYLIB), B, and C (both from PROJECT_LIB) and D (from MYLIB).
There are many reasons for using more than one physical library as
your virtual library:
o Using more than one library, you can improve LOAD performance
by loading multiple libraries simultaneously. See the help
topic Reducing_LOAD_Time.
o You can use virtual libraries to allow several developers to
maintain a consistent view of their changes to a project,
without affecting the other developers, and without having
to copy the entire SCA library for each developer.
o You can put your SCA libraries on different disks or on
different nodes (using the SCA server). This improves
performance or takes advantage of the available disk space.
o You can easily change the order of libraries in your virtual library
list with the INSERT LIBRARY BEFORE, INSERT LIBRARY AFTER, INSERT
LIBRARY FIRST, and INSERT LIBRARY LAST commands, eliminating the need
to reenter a library list. Libraries may also be removed from the list
with the CANCEL LIBRARY command. You can specify libraries in your
library list using library numbers. For example, the command CANCEL
LIBRARY 2 removes the second SCA library from the library list.