This lesson is aimed at providing a foundational overview for beginners while touching on advanced implications for experienced users.
What is CL?
Control Language (CL) is the native scripting and command-line language for IBM i systems, formerly known as AS/400 and iSeries. It serves as a powerful tool for system control, automation, and integration, distinct from application-focused languages like RPG or COBOL. CL has been a cornerstone since the late 1970s and maintains remarkable backward compatibility—programs written decades ago can run seamlessly on today's hardware.
This lesson explores CL from multiple angles: its origins, syntax, programming models, and real-world utility. We'll consider edge cases, such as transitioning from legacy to modern environments, and implications for career development in IBM i ecosystems. Examples will illustrate concepts, highlighting nuances like the balance between simplicity and power. Whether you're a system administrator automating backups or a programmer handling job queue processes, CL offers efficiency without the overhead of more complex languages.
Section 1: History and Evolution of CL
Core Concepts
CL originated with the IBM System/38 in the late 1970s and was formalized with the AS/400 launch in 1988. Through rebrandings AS/400 to iSeries (2000), System i (2006), and IBM i (2008 onward) - CL has evolved incrementally. Modern IBM i runs on Power Systems with logical partitions (LPARs), enabling multiple operating systems (e.g., IBM i, AIX, Linux) on a single machine.
Multiple Angles and Nuances
- Backward Compatibility: A key strength; 1990s-era CL programs execute without modification on current systems. This reduces migration risks but can lead to "spaghetti code" if not refactored.
- Modern Enhancements: Post-2008 updates introduced new commands and methods, improving integration with tools like SQL and web services. However, core syntax remains unchanged, allowing seamless upgrades.
- Contextual Implications: In enterprise settings, CL's stability supports long-term investments in legacy systems, but it also underscores the need for modernization to leverage cloud or hybrid environments.
- Edge Cases: Running CL on virtualized LPARs might introduce performance variances due to resource sharing, requiring monitoring tools.
Section 2: CL Command Structure
Core Concepts
CL commands follow a consistent verb-object format, typically three characters each (e.g., WRKACTJOB for "Work with Active Jobs," DSPUSRPRF for "Display User Profile"). This makes them intuitive for command-line use and scripting. Thousands of commands exist, covering object creation (e.g., CRTPF for physical files, CRTLF for logical files).
Multiple Angles and Nuances
- Ease of Use: The pattern aids quick learning but guessing commands risks errors so always consult IBM documentation.
- Scripting vs. Interactive: Commands shine in programs for automation, but interactive use via the command line is ideal for troubleshooting.
- Implications: In security-sensitive environments, improper command usage could expose vulnerabilities; pair with user authorities.
- Edge Cases: Custom commands can be created, extending CL, but over-customization complicates maintenance.
Examples
- Basic Command: SIGNOFF to log out, it's simple yet essential for session management.
- Object Creation: CRTPF FILE(MYLIB/MYFILE) RCDLEN(80) creates a physical file, illustrating parameter-based flexibility.
Section 3: Program Models - OPM vs. ILE
Core Concepts
- Original Program Model (OPM): Pre-iSeries; programs are standalone, compiled directly, and called hierarchically (e.g., one program retrieving data for others).
- Integrated Language Environment (ILE): Post-iSeries; uses reusable modules bound into programs. CL programs are CLP (OPM) or CLLE (ILE). Renaming source to CLLE allows ILE compilation without behavioral changes.
Multiple Angles and Nuances
- Reusability and Maintenance: ILE's modular approach reduces redundancy, update a module once, rebind everywhere. OPM suits simple tasks but scales poorly.
- Performance Considerations: ILE can be more efficient for large applications, but compilation overhead exists.
- Implications: For teams, ILE promotes collaboration via shared modules; solo developers might prefer OPM's simplicity.
- Edge Cases: Converting OPM to ILE may reveal hidden dependencies, necessitating thorough testing.
Examples
- OPM: A single CLP program calling another for data.
- ILE: A CLLE module handling customer data, bound into multiple programs for reuse.
Section 4: Variables and Data Types in CL
Core Concepts
Variables, prefixed with an ampersand (e.g., &NAME), pass data between commands. Types include:
- Character: Text (e.g., names, up to fixed lengths).
- Decimal: Numbers with decimals (e.g., dates as DDMMYY).
- Logical (Indicators): Boolean flags for conditions.
- Integer: Whole numbers.
- Unsigned Integer (UINT): For variable-length data, prefixed to indicate length (avoids padding issues).
- Pointer: Memory references for efficient large data handling.
Multiple Angles and Nuances
- Flexibility vs. Rigidity: Fixed lengths ensure predictability but waste space; UINTs mitigate this.
- Implications: In data-intensive tasks, pointers optimize memory, crucial for performance in high-volume systems.
- Edge Cases: Type mismatches cause runtime errors; always declare explicitly.
Examples
- Declaration: DCL VAR(&NAME) TYPE(*CHAR) LEN(50) for a name field.
- Usage: &DATE DEC(6 0) for a date without decimals.
Section 5: Program Flow Control
Core Concepts
CL supports structured constructs:
- Conditionals: IF/THEN/ELSE, SELECT/WHEN.
- Loops: DO/WHILE, DO/UNTIL. Avoid GOTO; use LEAVE/ITERATE for control.
Multiple Angles and Nuances
- Best Practices: Structured code improves readability; legacy GOTO leads to maintenance nightmares.
- Implications: In automation scripts, loops handle batch processing efficiently.
- Edge Cases: Nested loops risk infinite cycles, so implement timeouts.
Examples
- Conditional: IF (&STATUS *EQ 'SUCCESS') THEN(DO) ... ENDDO.
- Loop: DOUNTIL (&COUNTER *GT 10) ... ENDDO.
Section 6: Error Handling
Core Concepts
Use MONMSG for monitoring escape, notify, or status messages. On errors, invoke subroutines, send notifications (e.g., email, queues).
Multiple Angles and Nuances
- Robustness: CL's handling is user-friendly yet powerful, outshining some modern languages.
- Implications: Essential for production environments to prevent crashes.
- Edge Cases: Over-monitoring slows performance; target critical paths.
Examples
- Basic: MONMSG MSGID(CPF0000) EXEC(GOTO CMDLBL(ERROR)).
Conclusion
CL is an indispensable tool for IBM i, blending simplicity with depth for automation and control. Its evolution ensures relevance in modern IT, but mastering it requires practice in structured coding and error management.
By the end of this training, you’ll walk away with a clear understanding of why CL remains an essential skill on the IBM i. Whether you’re automating routine tasks like backups or building smarter workflows that support both administrators and developers. You’ll gain insight into the nuances of working with a language that must balance decades of legacy compatibility with modern development practices, including version control tools like Git. Mastering CL doesn’t just make your day‑to‑day work easier; it strengthens your long‑term career prospects in IBM i environments. Overlooking it is a bit like trying to drive without a steering wheel. As you continue exploring, consider experimenting with reusable templates, robust error‑handling routines, and additional hands‑on courses to deepen your expertise even further.