Command Sets

Command sets define how objects are built from your project. As the name implies a command set is composed of commands.

IBM® i objects such as modules, files, and programs are built from the source contained in your project. Each source file in your project can be associated with a command set to build it. The association of a command set with a set of source members is defined in a builder.

Other types of IBM i objects such data areas, service programs, and, authorization lists can be created as well. These kinds of objects are not built from source members, but are defined entirely by commands. You can use command sets to define these kinds of objects as well.

Command sets contain CL commands, which can contain variables. Since these variables can be set at build time, command sets can be considered to be templates for the creation of objects or for accomplishing various other tasks that might need to take place during the build of a project.

Command sets can be defined in the build spec of the project that uses them or they can be referenced as external command sets from other projects by first defining a project reference and then naming the command sets from that project you wish to use. You can use this capability to define a common set of command sets that every project uses.

Two Kinds of Command Sets

There are two kinds of command sets: general and conditional. General command sets are used to perform tasks that need to be run each build. These work well for set up, establishing overrides for compiles, packaging, and cleanup. Conditional command sets can be run or not based on the state of the output of the builder that is using it. That is, the commands in a command set could be run if the output object of a builder exists but is out-of-date, or if the output object does not exist at all.

Commands in a command set are grouped into processing sections. General command sets have only one processing section. Conditional command sets do their processing depending on the state of the output objects defined for the builders that use them. Conditional command sets have two sections one of which runs if the output object exists but is older than its inputs or dependencies and the other of which runs if the output object does not exist at all. A good example of where this might be necessary is if you want to create a physical file using CRTPF if it does not exist, and change it using CHGPF if it does exist. Data areas and other objects that hold data might need similar special processing. If there is no need to have the sections be different you can set the "does not exist" section to run the same commands as the "exists, but is out-of-date" section.

How Builders Run Command Sets

A builder will run a command set based on the kind of input processing you have specified in the builder that uses it. The commands in the command set are always run in the order you specify but may be run more than once depending on the type of input you have associated with it in the builder.

If you have specified a list of source objects or members as an input then the command set will be run once for each member of that list. This type of processing is suitable for compiling lists of members using a command such as CRTRPGMOD, CRTRPGPGM, or CRTBNDRPG. If you use command sets of this type you can use the following special variables to parameterize your commands:
&N
The name of the object or member in the source list.
&F
The name of the source file containing the member. This is the empty string if you have specified an object list.
&L
The name of the library containing the object or the member from the list.
&X
The descriptive text of the object or the member from the list.

If you do not specify a list of source objects or members then a conditional command set will be run at most once if the output object associated with the builder requires it. This is suitable for running commands that may take lists of objects as parameters such as CRTPGM.

General command sets are always run exactly once. These are suitable for commands or sets of commands that don't create objects, but could be a necessary part of build setup such as establishing overrides for compiles.

Commands and Substitution Variables

Commands have substitution variables whose values can be set when this command set is used by a builder. We have already mentioned the four special variables that can be used when you have an input you want to process one at a time. You may also define other variables just by using them in your commands. These variables are substitution variables, and are not CL variables. They do not need to be declared. They receive their values at the time they are executed and are substituted as strings only. They may receive these values from properties set from an Rational® Team Concert build definition, from other variables, or from string constants set in a builder or build specification. While they might look like CL variables there are both similarities and differences.
  • They do not need to be declared.
  • They begin with an ampersand (&) like CL variables.
  • They may consist of the 26 characters of the Roman alphabet (A-Z) in either upper or lower case, the digits 0-9, and the underscore (_). They must begin with a letter.
  • They may be up to 50 characters in length.
  • They are not case-sensitive. &ABC is equivalent to &abc.

Please refer to Jazz™.net for more information.


Feedback