SCLM is the Software Configuration and Library Manager component of ISPF which runs on z/OS®. It provides the source code management and build facilities of a software configuration manager (SCM). For example, SCLM supports Check out and Check in functions. SCLM provides a pessimistic locking model so that concurrent editing functions cannot be performed on a locked SCLM member. SCLM also provides build functions and a development hierarchy so that code, as it is developed and tested, can be promoted up to the next level of development. Such a hierarchy can exist in a tree structure as shown in the following figure. Other projects might have additional levels.

SCLM files are stored in SCLM projects. In SCLM terms, project refers to a set of SCLM data sets and controls. Other systems, such as Eclipse, use the word project: to mean different things. Files are stored in SCLM as members of partitioned data sets. These data sets are accessed through three level qualified names. The 1st qualifier, the high level qualifier, is the name of the SCLM project. The second qualifier is a group that acts as a level in the hierarchy. The third qualifier, called type, is generally a collection of similar parts within a group.
One or more development groups can also exist depending on the structure of the project. Code is developed initially at the lowest level (for example DEV1 or DEV2) and after being successfully built the code can be promoted to the next level, for example TEST. If testing is successful, that code can be promoted to Production. If code needs to be changed at either the Production or Test level, then that member is copied back to your development group and the code cycle starts over.
Each user of SCLM belongs to a development group. This determines what area of the project code you can access. Administrative tools exist for configuring the SCLM project. For more information about these tools, go to the SCLM Administrator Toolkit site at: http://www.ibm.com/software/awdtools/sclmsuite/admintoolk.
All members are described according to the following four level hierarchy:
Using this four level naming convention, any SCLM member can be described. The use of Group and Type is significant when retrieving project lists from SCLM and for adding IDE members to SCLM, as these values need to be specified.
The architecture definition (ARCHDEF) file is significant in SCLM because it is the principle method of describing how SCLM members should be built. SCLM uses the terminology Build as that is the process of creating output parts from an input part. A build is most commonly a compile, but is not limited to a compilation process. The analogy of an ARCHDEF is a Make file. The ARCHDEF describes the configuration of an application under SCLM control and how it is to be constructed and integrated. Architecture definitions are created and updated by the developers and describe the architecture of an application. However SCLM Developer Toolkit will also create and update architecture definition members when a project is added to SCLM or updated by the developer through the Package Explorer. In the case of Java applications stored in SCLM via SCLM Developer Toolkit the ARCHDEF will describe all the parts contained in a project plus their directory structure. ARCHDEFs can also be used as a means of obtaining a project listing, i.e. what parts actually make up the project that the ARCHDEF is describing. The ARCHDEF is the principle element for the build process for SCLM, so running an SCLM build against an ARCHDEF builds those members contained in the ARCHDEF or contained in nested ARCHDEFS, as many ARCHDEFS can exist and can reference other ARCHDEFS. When adding a file in a Java project to SCLM, SCLM Developer Toolkit will add it to an ARCHDEF file for that project, so the manifest of the Java project is always kept up-to-date. IBM® SCLM Developer Toolkit provides the ability to perform already defined build processes or to utilize the supplied Java/J2EE language definitions to build J2EE applications. These language translators are described in more detail in the SCLM Developer Toolkit Installation and Customization Guide, SCLM architecture definitions are described in the Software Configuration and Library Manager (SCLM) Guide and Reference
In traditional SCLM development on the mainframe source is often stored in different types such as COBOL, JCL, ASM, etc. This is fine in an environment where it is typical not to have same named parts in a project. However in the Java/J2EE world it is common for many Java/J2EE projects to have the same named parts. For example ear files typically have an application.xml. If we were to follow the normal SCLM model of placing all source for a particular type into the same library, then all of the files called “application.xml” would clash.
To this end, in order to fit all of these similar named types in an SCLM project, it is necessary to define an SCLM TYPE for each Java/J2EE project that will be stored in SCLM. Then within this TYPE all of the parts can be stored as each part within a Java/J2EE project will have a unique name. Plus different languages can be applied to different files to invoke different storage or build processes as required. An example of this is shown below:

The diagram shows the separation of members by type (J2EEPRJ1, J2EEPRJ2 and SOURCE). Different files are stored within each type and are differentiated by language. (JAVA, HTML, XML and COB2)
Within this development group, DEV1, the source stored in type J2EEPRJ1 could be the Java code and files required for a web project. Similarly for the source stored in type J2EEPRJ2. The source code stored in type SOURCE represents the COBOL host-based components for the web application, all stored in the same development group.
The Java code for the first web project is stored in SCLM in development group, DEV1, type J2EEPRJ1 with a language of JAVA.