Specifying the locations of included members

SCLM tracks two pieces of information for each include member that is found by a parser. The first piece of information is the member name of the include; the second is the include set that contains the included member. If no include set is returned by the parser for a member, SCLM assigns that member to the default include set. The name of the default include set is all blanks.

SCLM does not track an include member if it meets all of the following conditions:

The language definition for the member specifies CHKSYSLB=PARSE. This is the default.
An accounting record for the include is not found by searching the hierarchy for each type specified on the FLMINCLS for the include set.
The include is found in one of the data sets specified on an FLMSYSLB macro for the include set.

Includes that meet these conditions are removed from the list of includes stored in the accounting record of the member. Because the include is not being tracked, build and promote do not detect if the include is removed from the FLMSYSLB data sets or added to the project database.

Build ignores an include if it meets all of the following conditions:

The language definition for the member specifies CHKSYSLB=BUILD.
An accounting record for the include is not found by searching the hierarchy for each type specified on the FLMINCLS for the include set.
The include is found in one of the data sets specified on an FLMSYSLB macro for the include set.

Includes that meet these conditions are removed from the list of includes stored in the build map record of the member. Because the include is not being tracked, build and promote will not detect if the include has changed since the last build.

The include information is used by build and promote to determine whether the member is up-to-date. When you build, the includes for an up-to-date member have the same type, date, time, and version as the last time that member was built. When you promote, the includes for an up-to-date member have the same date, time, and version as the last time that member was built. Promote does not search the types listed on FLMINCLS macros for includes. It relies instead on the information in the build map to determine the type name of the included member. If a member is not up-to-date, build attempts to rebuild the member and promote does not allow the member to be promoted to the next group in the hierarchy.

An include set is used to associate an included member name with the type or types in the project that are searched to find a member with that name. The FLMINCLS macro is used to associate an include set with one or more types in the project definition. Types are searched in the order listed on the FLMINCLS macro. Each type is searched from the current group to the top of the hierarchy before the next type in the list is searched.

The number of include sets used by a language is usually related to the number of include ddnames supported by the build translators for that language, where the includes are located in project data sets. If the build translator only supports one include ddname, a single include set is sufficient for that language. On the other hand, if there are multiple build translators, each supporting an include ddname and the includes are separated into different types for each build translator, multiple include sets would be needed.

If multiple include sets are needed, parsers must return the appropriate include set for each include.