General conversion

Before doing the conversion, you should review the z/OS ISPF Software Configuration and Library Manager Guide and Reference, particularly these chapters:

"Defining the Project Environment", which describes the steps for setting up a project definition.
"Converting Projects to SCLM", which shows the steps for working with existing project data sets.

SCLM and LMF are similar in function, but there are some basic differences to consider when converting a project:

In SCLM, all data sets in the hierarchy are controlled. This includes the data sets where the developers do their editing (called the development level in SCLM). These data sets are not controlled in the LMF environment.
SCLM does not use a started task to update the controlled libraries. Users must have UPDATE authority to any level of the hierarchy that they must change, including the development level for editing, and any level into which they need to promote.
SCLM uses a VSAM data set to hold its control information. Control information includes information about where members exist in the hierarchy, statistics, and dependency information.
SCLM automates the BUILD step (compile, assemble, link-edit, and so on) and requires it to be done. This means SCLM must know what language is assigned to a part, and how the language is to be processed at BUILD time (called "SCLM Language Definition").
Output data, such as compiled object and load modules, can be automatically generated by SCLM. Review your processes to determine how to take advantage of SCLM's synchronization of source modules and assigned outputs.

To convert from LMF to SCLM, follow the steps listed in "Defining the Project Environment"in z/OS ISPF Software Configuration and Library Manager Guide and Reference. This takes you through the creation of the SCLM project definition and control data sets needed for SCLM.

The steps involved in defining the project environment are:

Determine the project hierarchy. For an existing project the hierarchy has already been defined, but a review is recommended.
Identify the types of data to support. Again, this has already been done with an existing project.
Establish authorization codes. Authorization codes control the movement of data within the hierarchy. The purpose of this step is to assign authorization codes to the hierarchy. Authorization codes restrict the drawdown and promotion of members to certain groups within the hierarchy. The concept is similar to LMF's concepts of authorized promoters and member access control, except that LMF uses userids and SCLM uses group names to restrict drawdown and promotion.
Allocate the PROJDEFS data sets. The PROJDEFS data sets are used to store the project definition data for an individual project. The project definition contains some of the same types of information as the LMF control file, such as the structure of the hierarchy.
Allocate the project partitioned data sets. Because you are using an existing project, most of these data sets already exist. Since all data sets are controlled in the SCLM environment, you will have to create development level data sets as part of the hierarchy for the developers to use when editing data.
Allocate and create the control data sets. Control data sets are used to track and control application programs within the hierarchy. There are 5 types of VSAM data sets that can be associated with a project:
Primary Accounting

The accounting data sets contain information about the software components in the project including statistics, dependency information and build maps (information about the last build of a member). At least one accounting data set is required for a project. The accounting data set contains some of the same types of information as the LMF control file, such as the member locking data.

Secondary Accounting

This is an optional backup of the information in the primary accounting data set.

Export Accounting

The export accounting data set contains accounting information that has been exported from the accounting data set. It is only required if the Import/Export functions of SCLM are used.

Primary Audit Control

The audit control data set contains audit information about changes to the software components in the project for groups that have auditing turned on. The audit data set contains the same types of information as the LMF activity log, as well as versions of members, if requested.

Secondary Audit Control

This is an optional backup of the information in the primary Audit Control data set.
Protect the project environment. This step should be reviewed because SCLM is structured slightly differently than LMF. Remember that developers must have UPDATE authority to the levels they need to change.
Create the project definition. The project definition is an assembler program, created using SCLM macros. Much of the definition is similar to the information that was entered in LMF's Library Controls (Option 8.1).
Assemble and link the project definition.

After the project has been defined, follow the steps in the z/OS ISPF Software Configuration and Library Manager Guide and Reference to put your existing project under SCLM control. In general, the steps are:

Prepare the hierarchy. Delete all unnecessary data from the libraries. If any groups are to be non-key, make sure they don't contain any data.
Create alternate project definitions.
Create architecture definitions for the project.
Register existing members with SCLM.