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:
- File property
- Build property
- Default value in translator
For a simple example, this PL/I compile translator uses a variable to indicate whether to generate compile listings:
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:
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.