Editable members and noneditable members are processed in separate and unique ways by SCLM.

Editable members, such as source members, are not created by the SCLM build function. Editable members must be registered with SCLM through the migration utility. Both the language associated with the member and a change code (only if you have a change code verification routine) are required as input to the migration utility. TEXT can be used as the language of members that do not need to be compiled, assembled, or processed, such as panels and messages. Call the migration utility for each library containing editable members.

The SCLM Build function creates noneditable members. Object code, listings, and load modules are examples of noneditable members. The SCLM build function must be called to create all of the noneditable members to be tracked within the hierarchy. If all of the customization related to language translators is complete and has been tested, run the build processor in the unconditional mode using the topmost architecture member for your application. This unconditional build will identify all build errors that exist. If errors are anticipated and the application is large, use architecture members with smaller scopes. For example, use an LEC architecture member rather than an HL. Using the conditional mode of the build processor causes processing to stop when a member containing an error is encountered.

The normal process is to migrate source members into SCLM and then generate the outputs using the SCLM Build function. There may be occasions, however, where you would like to use SCLM to manage object and load modules for which the source code no longer exists. There are two ways of doing this.

The first method uses a 'dummy' language definition with an FLMLANGL macro, but no FLMTRNSL macros. An example of this is provided as member FLM@OBJ in the ISP.SISPMACS data set included with SCLM. This language definition allows you to migrate object and load modules into SCLM as editable members in the same manner that source modules are introduced.

The second method involves migrating the object and load modules into a temporary type and then using the SCLM Build function to copy them to the target type. The SCLM build process will mark the copied object and load modules as non-editable. This solution is a better choice for projects with versioning in use. Member FLM@COPY in the ISP.SISPMACS data set can be used to store object modules into SCLM in this manner. It can be modified for use with load modules. This language definition will migrate the members into a temporary type as editable members. SCLM will allow the migrate because, like the FLM@OBJ language definition, there is no FLMTRNSL macro with FUNCTN=PARSE and therefore no parser will be invoked. The FLMTRNSL macro for the Build function calls IEBGENER to copy the modules from one SCLM type to the other as non-editable outputs.