Enterprise Extensions system definitions

To support a build with Ant with Enterprise Extensions, the source control component uses system definitions to capture and maintain supporting information. The following topics explain how this information is captured and maintained. The topics also introduce more fundamental source control component constructs to organize Enterprise Extensions artifacts.

Building and managing Enterprise Extensions source code

To build software, you might use job control languages (JCL) or a combination of JCL and code that is written in a scripting language like REXX. Commonly, a development team uses a combination of software for z/OS® or IBM® i and other distributed operating systems. This combination of software is especially likely when Enterprise Extensions functions are used on a web-based client. When you build on a distributed operating system, you might use scripting languages like MAKE or Ant to drive a build.

The Ant with Enterprise Extensions scripting language offers the functions and syntax of Ant, with extensions for building on a z/OS or IBM i system. With Ant with Enterprise Extensions, you can manipulate members of a partitioned data set (PDS) or a partitioned data set extended (PDSE). You can run z/OS or IBM i compilers to unify builds under a single scripting language.

To support z/OS or IBM i builds with Ant with Enterprise Extensions, the source control component captures and maintains supporting information. Ant with Enterprise Extensions is much like other source control component products, such as IBM SCLM. You specify all of this information one time in a system definition, and then use it continuously when you build.

Restriction: You must be a build administrator to make these kinds of specifications.
For more information about Enterprise Extensions builds, see Enterprise Extensions builds. Refer to Enterprise Extensions System Definition Ant Tasks for the ant build tools that expands the capability of the Enterprise Extension System Definition toolkit.

Ignoring changes to system definitions during dependency builds

After you create system definitions, you might decide to change the definition in some way. Normally when you change a system definition, a dependency build analyzes each buildable file. However, some changes you make to a system definition do not affect the output of the build. There is no need for a full analysis to be run for simple system definition changes. To enable dependency builds to skip the full analysis of buildable files, select the Ignore changes to this system definition for dependency builds check box. However, if you changed other files that require a full analysis, the full analysis is run. For information about dependency build analysis modes, see Running dependency builds on z/OS and IBM i systems.

Customizing and overriding system definition variables

You can customize system definitions with variables, whose values you assign through properties. You can also customize or override system definition variables at a file level, for files that are associated with a specific language definition. Specifying variables at a file level is useful when you want to override a property in the translator for a specific file. For example,: one of your translators runs the compilation for all of your COBOL source files, but for one specific COBOL file you want to specify a different compiler option. You can specify a variable in the translator with default compiler option that applies to all COBOL source files, and override the variable at the file level for this specific COBOL file.

You can define system definition variables in the following editors:
  • Translator editor
  • Build definition editor
  • File properties editor
A language definition can contain multiple translators. Because some variables are defined at the translator level, you can have two or more translators that define the same variable with different default values. When that happens, you can override a variable to a single value only; for example:
  • Translator_A contains Variable_1 with the default value Value_A
  • Translator_B contains Variable_1 with the default value Value_B
  • If you override Variable_1 to Value_C at either the file or build definition level, both Variable_1 in Translator_A and in Translator_B are overridden to Value_C.
Note: To override variables in different translators with different values, you must define those variables with different names.

Use the System Definitions Generator filemetadata task to set file-level user properties to override default translator variables. Define those file-level properties with the name team.enterprise.build.var.(variable name).

z/OS and IBM i SCM terms

As you read more about z/OS and IBM i, notice several terms that relate specifically to z/OS and IBM i:
  • Data set definition
  • Data set prefix
  • Language definition
  • Library
  • Library definition
  • Sandbox
  • Search path
  • Translator
  • Workspace
  • zComponent
  • zComponent Project
  • zFile
  • zFolder
For the definitions of these terms, see the Engineering Workflow Management glossary at Glossary for the Rational® solution for Collaborative Lifecycle Management.
For details about each of the Enterprise Extensions system definitions, see one of the following topics:

video icon Video

Jazz.net channel
Software Education channel

learn icon Courses

IoT Academy
Skills Gateway

ask icon Community

Jazz.net forums
Jazz.net library

support icon Support

IBM Support Community
Deployment wiki