CLLE

CLLE (Control Language — ILE) is the Integrated Language Environment version of IBM’s Control Language for the IBM i platform, formerly known as AS/400 and iSeries. While CL itself dates back to the IBM System/38 in 1979, CLLE specifically refers to CL programs compiled under the ILE model, which was introduced in the early 1990s. CLLE serves as the primary system administration and program integration language on IBM i, used to manage jobs, manipulate objects, control program flow, and orchestrate interactions between application programs written in RPG, COBOL, C, and other ILE languages.

History & Origins

Control Language has its roots in the IBM System/38, which shipped in 1979. The System/38 introduced a command-based interface for system operations, where each system function was invoked through a structured CL command with a verb-noun naming convention (e.g., CRTLIB for Create Library, WRKJOB for Work with Job). This design philosophy carried forward when IBM launched the AS/400 on June 21, 1988, with CL as the primary system control language under OS/400.

In the original AS/400 environment, CL programs were compiled under what is now called the Original Program Model (OPM). OPM CL programs (source type CLP) were self-contained: each program was independently compiled and could call other programs, but there was no mechanism for binding multiple modules together or sharing activation state between programs.

The Arrival of ILE

On February 16, 1993, IBM announced OS/400 V2R3, which introduced the Integrated Language Environment (ILE). ILE represented a fundamental shift in how programs were structured on the AS/400. Rather than each program being a standalone executable, ILE allowed programs from different languages to be compiled into modules and bound together into a single program object or service program.

However, V2R3 initially shipped with only ILE C/400. The broader ILE rollout came with OS/400 V3R1 in 1994, which delivered ILE RPG/400 and ILE COBOL/400. ILE CL became available around this period, introducing the CLLE source type. The exact release in which ILE CL first appeared is not consistently documented across sources — some references associate it with V3R1, while others place it slightly later in the V3R1–V3R2 timeframe.

With the introduction of ILE CL, the source member type changed from CLP (CL Program) to CLLE (CL — ILE), and the creation command changed from CRTCLPGM to CRTBNDCL (Create Bound CL Program) or the two-step CRTCLMOD/CRTPGM process.

Design Philosophy

CLLE inherits CL’s fundamental design as a command-oriented system language. Its core principles reflect the IBM i environment:

Command-driven architecture: Every operation in CLLE is expressed as a CL command. The language provides over 2,000 system commands, each following the consistent verb-noun naming convention. This makes CLLE both a programming language and a direct interface to the operating system.

System integration: CLLE is designed to orchestrate rather than compute. Its strength lies in managing system resources — jobs, queues, libraries, files, subsystems — and coordinating the execution of application programs written in languages like RPG and COBOL.

ILE modularity: Unlike OPM CL programs, CLLE programs can be compiled as modules and bound with modules written in other ILE languages. This allows CL logic to coexist within the same program object as RPG or COBOL business logic, sharing activation groups and enabling direct procedure calls.

Key Features

ILE-Specific Capabilities

The primary distinction between CLLE and its OPM predecessor lies in ILE features:

• Modules and binding: CLLE source can be compiled into a module (CRTCLMOD) and bound with other modules into a single program (CRTPGM) or service program (CRTSRVPGM)
• Service programs: CLLE procedures can be packaged in service programs, enabling shared utility functions that are bound by reference rather than copied
• Activation groups: CLLE programs can specify activation groups, controlling how program state is managed and shared across calls
• Bound calls: Direct procedure calls between ILE modules avoid the overhead of dynamic program calls

Variables and Data Types

CLLE supports the DCL (Declare) command for variable declaration with character, decimal, logical, integer, and pointer types:

1
2
3
4
5
6
7
8

PGM
  DCL VAR(&NAME) TYPE(*CHAR) LEN(50)
  DCL VAR(&COUNT) TYPE(*DEC) LEN(5 0)
  DCL VAR(&FOUND) TYPE(*LGL)

  CHGVAR VAR(&NAME) VALUE('World')
  SNDPGMMSG MSG('Hello,' *BCAT &NAME *TCAT '!')
ENDPGM

Control Structures

CLLE supports structured programming constructs that were enhanced over successive IBM i releases:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

PGM PARM(&ACTION)
  DCL VAR(&ACTION) TYPE(*CHAR) LEN(10)
  DCL VAR(&COUNT) TYPE(*DEC) LEN(5 0)

  IF COND(&ACTION *EQ 'LIST') THEN(DO)
    /* List processing logic */
    DSPLIB LIB(*USRLIBL)
  ENDDO
  ELSE CMD(DO)
    SNDPGMMSG MSG('Unknown action:' *BCAT &ACTION)
  ENDDO

  /* DOFOR loop - added in later IBM i releases */
  DOFOR VAR(&COUNT) FROM(1) TO(5)
    SNDPGMMSG MSG('Iteration' *BCAT %CHAR(&COUNT))
  ENDDO
ENDPGM

Subroutine support (SUBR/ENDSUBR) was added in i5/OS V5R4 (2006), providing a way to organize code within a CLLE program without requiring separate modules.

Built-in Functions

IBM has progressively added built-in functions to ILE CL, including:

• %SST — Substring extraction
• %SCAN — String scanning
• %TRIM, %TRIML, %TRIMR — String trimming
• %CHECK — Character checking
• %CHAR — Convert to character
• %DEC, %INT — Numeric conversions
• %LEN — Length operations
• %SWITCH — Job switch evaluation

File Operations

CLLE can read database files using DCLF (Declare File), RCVF (Receive File), and SNDF/SNDRCVF for display files:

1
2
3
4
5
6
7
8
9

PGM
  DCLF FILE(CUSTFILE)

  DOWHILE COND('1')
    RCVF
    MONMSG MSGID(CPF0864) EXEC(LEAVE)
    SNDPGMMSG MSG('Customer:' *BCAT &CUSNAM)
  ENDDO
ENDPGM

Message Handling

CL’s message-based architecture is a distinctive feature. Programs communicate through messages, and CLLE provides commands for sending, receiving, and monitoring messages:

1
2
3
4
5
6
7

PGM
  /* Monitor for a specific error */
  CALL PGM(MYPROGRAM)
  MONMSG MSGID(CPF0000) EXEC(DO)
    SNDPGMMSG MSG('An error occurred') TOPGMQ(*PRV)
  ENDDO
ENDPGM

The MONMSG command is CLLE’s error handling mechanism, allowing programs to intercept specific message IDs and take corrective action.

Evolution

CLLE’s evolution has been shaped by the broader IBM i platform trajectory:

• 1979–1988: CL originates on System/38 and carries forward to AS/400 as an OPM language (source type CLP). Provides system command automation with basic variable support and control flow.
• 1993–1995: ILE introduced on AS/400. ILE CL (CLLE) emerges, enabling modular compilation, binding, and service programs. The language gains the ability to participate in mixed-language ILE programs.
• 2000–2006: Platform rebranded to iSeries. V5R3 (2004) adds DOWHILE, DOUNTIL, DOFOR loops, SELECT/WHEN, and integer types. V5R4 (2006) adds subroutines, pointers, and data structures. The gap between OPM CL and ILE CL capabilities widens as new features are added primarily to the ILE model.
• 2008–present: Platform becomes IBM i. Continued enhancements including additional built-in functions for string handling and improved integration with modern IBM i features like SQL services and open-source tools.

Converting from OPM to ILE

Migration from CLP to CLLE is straightforward in most cases. Changing the source member type from CLP to CLLE and using CRTBNDCL instead of CRTCLPGM is sufficient for most programs. The primary incompatibility is the TFRCTL (Transfer Control) command, which has no direct ILE equivalent and must be replaced with CALL or procedure calls.

Current Relevance

CLLE remains actively supported and enhanced on IBM i, with the latest release being IBM i 7.6 (GA April 18, 2025). IBM continues to add new CL commands and built-in functions with each release and Technology Refresh, and CLLE is the recommended compilation model for all new CL development on IBM i.

The IBM i platform has an estimated installed base of over 100,000 systems worldwide, concentrated in industries such as banking, insurance, manufacturing, distribution, and retail. CLLE is used on virtually every one of these systems for system administration tasks, and on most of them for application integration and job orchestration.

IBM’s modernization strategy for IBM i includes open-source integration (Node.js, Python, and PHP run natively on IBM i), but CLLE retains its role as the system-level glue language. Modern IBM i development practices combine RPG or SQL for business logic with CLLE for system operations, job management, and program coordination.

The IBM i community remains active through organizations like COMMON (the IBM i user group), online resources such as IT Jungle, MC Press, and numerous IBM i-focused blogs and forums.

Why It Matters

CLLE represents the evolution of a system control language that has been in continuous use for over four decades (counting from CL’s System/38 origins in 1979). Its significance lies in several areas:

Platform longevity: CLLE and the IBM i platform demonstrate that backward compatibility and incremental modernization can sustain a computing platform across decades. CL programs written in the 1980s (in OPM form) still run on current IBM i systems, and the transition to CLLE preserved existing investment while adding modern capabilities.

ILE as an integration model: The Integrated Language Environment that CLLE participates in was an early and successful implementation of mixed-language programming at the system level. The ability to bind CL, RPG, COBOL, C, and C++ modules into a single program object anticipated modern polyglot programming approaches.

Command-oriented design: CL’s consistent verb-noun command structure, with over 2,000 commands following the same pattern, represents one of the most systematic approaches to operating system interface design. This consistency makes the system discoverable and learnable despite its complexity.

Enterprise reliability: IBM i systems running CLLE are known for exceptional uptime and reliability in mission-critical environments. The platform’s single-level storage architecture and integrated database (Db2 for i) create an environment where CLLE can manage system resources with a level of integration that is difficult to achieve on other platforms.