O SCLM é o componente Software Configuration and Library Manager do ISPF que é executado no z/OS . Fornece os recursos de gerenciamento e construção do código de origem de um SCM (Software Configuration Manager). Por exemplo, o SCLM suporta as funções de Registro de Saída e de Entrada. O SCLM fornece um modelo de bloqueio pessimista, para que funções de edição simultânea não possam ser desempenhadas em um membro bloqueado do SCLM. O SCLM também fornece funções de construção e uma hierarquia de desenvolvimento, para que o código, enquanto é desenvolvido e testado, possa ser promovido para o próximo nível de desenvolvimento. Essa hierarquia pode existir em uma estrutura em árvore, conforme mostrado na figura a seguir. Outros projetos poderiam ter níveis adicionais.

Os arquivos SCLM são armazenados em projetos SCLM. Em termos do SCLM, projeto refere-se a um grupo de conjuntos de dados e controles do SCLM. Outros sistemas, como o Eclipse, utilizam a palavra projeto: com diferentes significados. Os arquivos são armazenados no SCLM como membros de conjuntos de dados particionados. Esses conjuntos de dados são acessados por meio de nomes qualificados em três níveis. O primeiro qualificador, de alto nível, é o nome do projeto SCLM. O segundo qualificador é um grupo que atua como um nível na hierarquia. O terceiro qualificador, chamado de tipo, é geralmente uma coleta de partes similares dentro do grupo.
Um ou mais grupos de desenvolvimento também podem existir, dependendo da estrutura do projeto. O código é desenvolvido inicialmente no nível mais baixo (por exemplo DEV1 ou DEV2) e após a construção bem-sucedida, o código pode ser promovido para o próximo nível, por exemplo, TESTE. Se o teste for bem-sucedido, esse código poderá ser promovido para Produção. Se o código precisar ser alterado no nível de Produção ou de Teste, este membro será copiado para o grupo de desenvolvimento e o ciclo de código inicia novamente.
Cada usuário do SCLM pertence a um grupo de desenvolvimento. Isso determina qual área do código do projeto é possível acessar. Existem ferramentas administrativas para configurar o projeto SCLM. Para obter mais informações sobre essas ferramentas, vá para o site do SCLM Administrator Toolkit: http://www.ibm.com/software/awdtools/sclmsuite/admintoolk.
Todos os membros são descritos de acordo com o seguinte hierarquia de quatro níveis:
Usando essa convenção de nomenclatura de quatro níveis, qualquer membro SCLM pode ser descrito. A utilização de Grupo e Tipo é importante para recuperar listas de projetos do SCLM e para incluir membros IDE no SCLM, uma vez que esses valores precisam ser especificados.
O arquivo de definição de arquitetura (ARCHDEF) é importante no SCLM porque consiste no método principal para descrever como os membros SCLM devem ser construídos. O SCLM utiliza a terminologia Construção, que é o processo de criar partes de saída a partir de uma parte de entrada. Uma construção é geralmente uma compilação, mas não está limitada a um processo de compilação. A analogia de um ARCHDEF é um arquivo Make. O ARCHDEF descreve a configuração de um aplicativo sob o controle do SCLM e como ele será construído e integrado. As definições de arquitetura são criadas e atualizadas pelos desenvolvedores e descrevem a arquitetura de um aplicativo. Entretanto, o SCLM Developer Toolkit também criará e atualizará os membros de definição da arquitetura quando um projeto for incluído no SCLM ou atualizado pelo desenvolvedor através do Package Explorer. No caso de aplicativos Java™ armazenados no SCLM por meio do SCLM Developer Toolkit, o ARCHDEF descreverá todas as partes contidas em um projeto, além de sua estrutura de diretórios. Os ARCHDEFs também podem ser utilizados como um meio de obter uma listagem de projetos, isto é, quais partes realmente constituem o projeto que está sendo descrito pelo ARCHDEF. O ARCHDEF é o elemento principal para o processo de construção do SCLM, portanto a execução de uma construção do SCLM em um ARCHDEF constrói os membros contidos no ARCHDEF ou contidos em ARCHDEFS aninhados, tantos quanto puderem existir e referenciar outros ARCHDEFS. Ao incluir um arquivo em um projeto Java para o SCLM, o SCLM Developer Toolkit o inclui em um arquivo ARCHDEF desse projeto, portanto o manifesto do projeto Java é sempre mantido atualizado. O IBM® SCLM Developer Toolkit fornece a capacidade de executar processos de construção já definidos ou de usar as definições de linguagem Java/J2EE fornecidas para construir aplicativos J2EE. Essas conversões de linguagem são descritas com mais detalhes no SCLM Developer Toolkit Installation and Customization Guide, as definições de arquitetura do SCLM são descritas no Software Configuration and Library Manager (SCLM) Guide and Reference
O desenvolvimento SCLM tradicional na origem do mainframe é frequentemente armazenado em tipos diferentes tais como COBOL, JCL, ASM, etc. Isso é bom em um ambiente em que é típico não possuir as mesmas partes nomeadas em um projeto. Entretanto, no universo Java/J2EE, é comum que muitos projetos Java/J2EE tenham as mesmas partes nomeadas. Por exemplo, os arquivos ear possuem geralmente um application.xml. Se fosse seguido o modelo SCLM normal, que coloca toda a origem de um tipo específico na mesma biblioteca, haveria conflito de todos os arquivos denominados "application.xml".
Para essa finalidade, para ajustar todos os tipos nomeados semelhantes em um projeto SCLM, é necessário definir um SCLM TYPE para cada projeto Java/J2EE que será armazenado no SCLM. Por conseguinte, todas as partes poderão ser armazenadas dentro desse TYPE, visto que cada parte dentro de um projeto Java/J2EE terá um nome exclusivo. Além disso, linguagens diferentes podem ser aplicadas a arquivos diferentes, para chamar processos de armazenamento ou construção diferentes, conforme necessário. Um exemplo disso é mostrado a seguir:

O diagrama mostra a separação de membros por tipo (J2EEPRJ1, J2EEPRJ2 e SOURCE). Arquivos diferentes são armazenados dentro de cada tipo, os quais são discriminados pela linguagem. (JAVA, HTML, XML e COB2)
Dentro deste grupo de desenvolvimento, DEV1, a origem armazenada no tipo J2EEPRJ1 poderia ser o código Java e os arquivos necessários para um projeto da Web. Semelhantemente à origem armazenada no tipo J2EEPRJ2. O código de origem armazenado no tipo SOURCE representa os componentes COBOL baseados em host para o aplicativo da Web, todos armazenados no mesmo grupo de desenvolvimento.
O código Java para o primeiro projeto da Web é armazenado no SCLM no grupo de desenvolvimento, DEV1, tipo J2EEPRJ1, com uma linguagem JAVA.