Specifying compiler options on a per file basis using translator variables

When building your mainframe applications with Rational Team Concert, you capture your compiler options in a translator. The translator represents one step in your build process, such as a compile or a link-edit. The translator belongs to a language definition, which gathers and orders all of the steps necessary to build a file. Each file that needs to be built is associated with an appropriate language definition. So, you’d have one language definition for your main COBOL programs, another for your subroutines, yet another for your BMS maps, and so on. But what do you do if not all of your files of any given type require the same compile or link options? Or if you want to use different options depending on if you are building at DEV or TEST?

Starting in RTC V4.0, you can use variables in your translator when you specify your compile options. You provide a default value for the variable in the translator, and then can override that value at the file or build definition level. The order of precedence for resolving the variable value at build time is:

  1. File property
  2. Build property
  3. Default value in translator

For a simple example, this PL/I compile translator uses a variable to indicate whether to generate compile listings:

Translator with variable

Translator with variable

The default value is LIST. If you want to specify NOLIST for a particular file, you provide the override in the file properties like so:

File level compiler option override

File level compiler option override

If you want to specify NOLIST for all files, you can use a build property that you add to the build definition or the build request. You create the build property by adding the prefix team.enterprise.build.var to the variable name. So, in this example, we would create a build property of name team.enterprise.build.var.LISTING and give it a value of NOLIST to override the translator default value.

Variables can be used in the “Command/member” field for ISPF/TSO command or exec translators, and in the “Default options” field for called program translators. For more information, visit the Information Center.

About these ads
This entry was posted in Uncategorized. Bookmark the permalink.

One Response to Specifying compiler options on a per file basis using translator variables

  1. Dennis says:

    Hi Robin, thank you very much for this article. I use it for the TEST/NOTEST Debug Option.

    One comment: I have just seen, that the overwrites are only supported on dependency based build definitions. See https://jazz.net/forum/questions/99394/translator-variables-in-dependency-based-build-and-ant-with-ee-build

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s