There are two schemes for deploying a release of an application: you can replace all the objects in the application or you can replace only the ones that have changed. Many applications on the IBM® i are deployed by installing patches or fixes over a base set of objects. We call this set of new objects a "fix pack". As an application moves through releases it accumulates a set of fix packs and over time there will be several fix packs to a particular base. You can construct these fix packs so that they need to be applied serially or so that they are cumulative. You can also construct fix packs so that they replace existing objects or set the library list search path so that the fix pack objects are resolved instead of the existing objects.
Consider this example. An application consists of a number of programs, files, and other objects all residing in a small set of libraries. These libraries are all present in the library list when a user runs the application. A fix pack to the application replaces some of the objects of those libraries with newer versions, leaving the other ones intact. Due to the late binding nature of service programs in ILE and programs in general in the OPM, replacing these objects results in a new version of the application being made available.
Alternatively, the user may elect to place the libraries of the fix pack ahead of the base application in the library list and allow dynamic binding to take place using the library list. If all the binding is done using the library list, this effectively applies the fix pack without replacing any of the objects in the base library.
You can use Rational Team Concert to construct fix packs of either kind.
In this example we'll assume we have two source libraries FIX and BASE. For simplicity, we'll also assume that the application objects will be created directly into the FIX library. The source file BASE/QRPGLESRC contains members A and B. The source file BASE/QRPGLEINC contains member I. I is an included member used by both A and B. In this example all include source is placed in QRPGLEINC and given the source type RPGLE. We consider BASE to be read-only. All changes are made in FIX. Assume also that BASE contains all the objects created from source in BASE and that FIX contains the objects that will comprise the fix pack. Initially FIX is empty.
The programmer wishes to modify QRPGLESRC(A). To do this she must copy QRPGLESRC(A) from BASE to FIX. She does so and modifies the member. A build should create the module FIX/A from this source.
The programmer now wishes to modify QRPGLEINC(I). She copies that to QRPGLEINC(I) from BASE to FIX and makes the modification. A build should now create module FIX/A from this source, but also create module FIX/B. There is no module associated with QRPGLEINC(I) even though it is of type RPGLE since it is an included member and should not be compiled.
The project organization, build set up, and the build process must be flexible enough to determine the following:
The basic project organization for this example in the i Projects support in Rational Developer for Power Systems Software is very simple. There is a single project with two source files: QRPGLESRC and QRPGLEINC. Each source file holds the members mentioned above. Notice that there is only one project. Since the repository keeps track of the whole history of this project its contents can vary over time. There is no need to establish a separate project to make an enhancement or fix to an application.
We can share this project into a repository stream. Within this stream we will create a snapshot that will be the base for this application. In this example we will assume that the BASE library has already been populated.
As we begin to make changes to the application the stream will hold the changes we make. We associate a build workspace and its build definition with this stream. The build definition will have the FIX library on the IBM i as its load and object library. This build definition will have the BASE library in its build definition as the only one of its reference libraries.
Before a build is submitted the snapshot load process keeps the FIX library and the build workspace synchronized. As changes are made to the stream, they will flow to its build workspace and from there to the FIX library on the IBM i system. However, since we have established a base snapshot , only files that are different than the base will be loaded into the fix library.
In our example, the programmer makes a change to QRPGLESRC(A) and then delivers that change to the stream. This causes the change to flow to the build workspace. Since it is a change over the base, the member is then loaded into the FIX library on the IBM i system. Likewise QRPGLEINC(I) has been changed and it flows into the FIX library. Our FIX library now contains two source members.
A library list consists of four sections: the system library list, the current library, one or two product libraries, and the user library list. We'll ignore the system and product sections of the library list for now. The current library is a single library. The user library list is multiple libraries. A library may be the current library and also appear in the user library list, but there cannot be duplicates in the user library list.
Using our previous example, it is clear we want to compile into FIX. This should be our current library. All create commands will create objects in this library by default. Since we are compiling objects into FIX, we specify that in our build definition.
BASE needs to be in the library list as well in order for the members to be found by the compilers. This will be the only library in our user library list. We specify it in our build definition as a reference library.
The library list can also contain other library after BASE. However, we looking for candidates to compile we want to search only in FIX and BASE and not the subsequent libraries.
The build specification directs the build process by describing what is built and how it is to be built. In our example, the build specification for the project has two command sets: one for ILE RPG and one to create any programs from the modules. The build specification also has two builders, one that describes what to compile for RPG and one to create the program. Ordinarily we would be able to reuse the command sets among multiple builders, but since this is a simple example there is no reuse.
To summarize, we have QRPGLESRC(A) of source type RPGLE in both FIX and BASE. We have QRPGLEINC(I) of source type RPGLE in FIX and BASE. We have QRPGLESRC(B) in BASE. Both A and B include I.
The build process needs to examine all compile candidates in QRPGLESRC of type RPGLE. Since the library list may contain libraries other than FIX and BASE we describe the list of candidates using the special variable &SP. This variable contains the libraries from the project that must be searched when looking for source to compile. In our case, &SP is set by the build engine to be the list (FIX BASE).
In our builder definition we define the expression of compile candidates as the following:
We also define the list of potential dependencies as:
Applying the first expression to our example gives us the following compile candidates after FIX/QRPGLESRC(A) has been created and modified:
Applying the second expression to our example gives us the following list of dependencies for these candidates:
Thus, changing QRPGLEINC(I) will cause FIX/QRPGLESRC(A) and BASE/QRPGLESRC(B) to compile creating modules FIX/A and FIX/B. Changing just QRPGLESRC(A) will cause only FIX/QRPGLESRC(A) to compile creating module FIX/A Thus, the library FIX will contain only those modules needed for a fix pack.
Please refer to Jazz™.net for more information.