Differences between IBM i Build Definitions explained

This blog post goes over the different build definitions specific for IBM i and the common scenarios they are used in.  When looking at moving Builds over to Rational Team Concert it can be a bit confusing to figure out which build definition template to use.

To start off, the build definitions are differentiated by the engines they use. Rational Team Concert has multiple engines, the ones supported by IBM i are the Jazz Build Engine and Rational Build Agent.  The Jazz Build Engine is used by our older build definitions, while our newer build definitions use the Rational Build Agent.  The Rational Build Agent is the build agent used by Build Forge, which means if you already are using it today you can reuse the same agent with RTC.

IBM i Continuous Load
The IBM i Continuous Load build definition uses the Jazz Build Engine.  This definition will not actually build(compile) anything.  It is used specifically for loading the contents of your Streams to some mapped Libraries on the IBM i.  This is used by some teams when first adopting RTC to allow them to reuse their old build/compilation process.  With this definition they can get the source out of the RTC Streams and run their own build/compilation process.  You can setup a schedule so the continuous load runs every 5 mins, every hour, or any time amount you desire and each time it runs it will load only what has changed since the last load.  Find out more in the InfoCenter.

IBM i Command
Like the IBM i Continuous Load definition this definition uses the Jazz Build Engine.  It is used by teams that have a certain command they run to build/compile their applications.  For example if you have a CL command you can use that with this definition.  You have the ability to have a command run for every changed member or to run one command for all members that have changed.  The options for what to load are to load the entire application each time or just load the changes since the last build.  Find out more in the InfoCenter.

IBM i Build Specification (Deprecated as of RTC 4.0)
The IBM i Build Specification build was the first build definition to use the Rational Build Agent.  This was the beginning of our builds to start doing dependency analysis.  It uses a Build Specification created in every IBM i Project that defines the commands to run for various inputs.  In addition to that we have scanners that run in the background to analyze certain dependencies, so we will rebuild for example all RPGLE members if the include file they use has changed.  We deprecated this style of build in RTC 4.0, as we introduced the IBM i Dependency Build.  Read below for details on it.  This does not mean we will remove the IBM i Build Specification build definition in the next release it just means we do not recommend it be used for dependency based builds, as the recommended approach is now the IBM i Dependency Build.  If you are currently using the IBM i Build Specification build you should start investigating the IBM i Dependency Build as it has more dependency analysis available in it and more.  For more details read the end-to-end article.

IBM i Dependency Build
The IBM i Dependency Build uses the Rational Build Agent.  This build definition is very similar to the z/OS Dependency Build definition as we are now using the same framework between IBM i and z/OS for our dependency builds instead of having separate technologies like we did before with the Build Specification.  This means when we do improvements you will likely see it for both platforms!  This style of definition uses System Definitions instead of a Build Specification for specifying how to compile your application.  More information on System Definitions can be found in this great article that explains it all.  This style of build is used by teams that want to take advantage of dependency analysis instead of having in-depth knowledge of various parts of their application and having to know when it needs to be recompiled.  Refer to this wiki page for details on what scanners are available and the types of dependencies they can find.

Additional Links:
Starting and Stopping the Jazz Build Engine
Installing and Configuring the Rational Build Agent


RTC Enterprise Extensions Useful Links

It can be hard to find the information you are looking for sometimes and over time we have built up a great list of bookmarks that we are constantly sending to everyone when they have questions or referring back to ourselves.  To make these bookmarks accessible to everyone we have started a Useful Links page, so everyone can easily find information they are looking for.  We have broken the page down into links by functionality.

This page is a work in progress, but if you find we are missing any links that you use and find helpful let us know by commenting and we will add it to the list.  We will be continuing to keep it updated as the team produces more content.

Auto Clean Demystified

The Auto Clean option available in the Package Definition is used to cleanup unwanted packages or packages that have already been deployed from the package root directory. This is done by deleting package results. When a package result is deleted it gets marked to delete the package from the package root directory, on the next create package request.

Steps for setting up and using auto clean:

  1. The package definition includes an Auto Clean option in the Options tab that should be selected.
  2. The packaging result associated with the package that needs to be cleaned should be deleted, thereby marking the actual package for deletion.
  3. Under the default setting the user will have to wait up to 30 minutes after the package result is deleted and then on the next Create Package… request, the Auto Clean will take place and all marked packages will be deleted.

Note: This happens because the “Build Result Pruner Task Fixed Delay (seconds)” runs every 30 minutes by default and checks for any package results that have been deleted and marks those packages for deletion. If a Create Package is requested before the pruner task has run, the packages will not be deleted and a subsequent Create Package will have to be requested.

Additional information on Auto Clean

  1. The 30 minute delay can be changed by changing the advanced property “Build Result Pruner Task Fixed Delay (seconds)” on the server in the Change and Configuration Management Advanced Properties page. Go to the Build System section and change the Current Value field of the Build Result Pruner Task Fixed Delay property and Click Save.
  2. A failed package is automatically removed from the package root directory even if you do not select the Auto clean option.