Dynamic include tracking

The SCLM build processor attempts to resolve all include references to source members before it invokes any translator. However, for some translators, the include for a source member cannot be resolved until after the translator invocation. Such includes are referred to as dynamic includes. SCLM can track dynamic includes if the dynamic includes for a member can be altered only by modification of the member or one of the included members.

To support dynamic includes, SCLM invokes an additional build translator step (FLMTRNSL macro) following the translator that produces the output data set containing a list of dynamic includes. This additional translator should parse the output data set for dynamic includes and store them in memory supplied by the build processor. You pass the address of this memory to the translator by specifying the SCLM variable @@FLMINC in the translator options (OPTION parameter on FLMTRNSL macro). @@FLMINC is a pointer to a set of includes relating to a specified member. The value of @@FLMINC is a string of decimal characters that you must convert to a fullword binary value before using it as an address. The following record layout is used to store the dynamic includes:

Figure 1. Record Layout Used to Store Dynamic Includes

   COUNT    : 4 bytes
   TYPE1    : 8 bytes
   MEMBER1  : 8 bytes
   TYPE2    : 8 bytes
   MEMBER2  : 8 bytes
       .
       .
       .
   TYPE#    : 8 bytes
   MEMBER#  : 8 bytes

You must specify the number of dynamic includes in the first 4 bytes as a fullword binary integer, followed by the list of dynamic include member and type names. The amount of memory that the SCLM build processor supplies limits the number of dynamic includes to 1000.

When using dynamic includes, consider the following points:

Be sure to remove any duplicate include references before placing them in the structure pointed to by @@FLMINC.
Processors need the ability to handle 31-bit addresses as specified by the @@FLMINC parameter.
Do not return any include references that are actually to external (non-SCLM) libraries. The build step will receive an error (FLM01001) for any members not in the specified SCLM library.
Deletion of members referenced through a dynamic include causes a build verification error (FLM43001). The build process does not proceed, even when using unconditional mode. If a referenced member is to be deleted, a build using the updated source should be performed before the deletion so that the build map can be updated to remove the reference.
Dynamic include references to members that are outputs of other members do not cause a relationship to the member that created it, even when using extended mode. Builds and promotes for these must use a high-level architecture definition whose scope includes both source members.