A CL procedure is a group of CL commands that tells the system where to get input, how to process it, and where to place the results. The procedure is assigned a name by which it can then be called by other procedures or bound into a program and called. As with other kinds of procedures, you must enter CL procedure source statements, compile, and bind them before you can run the procedure.
When you enter CL commands individually (from the Command Entry display, for instance, or as individual commands in an input stream), each command is separately processed. When you enter CL commands as source statements for a CL procedure, the source remains for later modification if you choose, and the commands are compiled into a module. This module remains as a permanent system object that can be bound into other programs and run. Thus, CL is actually a high-level programming language for system functions. CL procedures ensure consistent processing of groups of commands. You can perform functions with a CL procedure that you cannot perform by entering commands individually, and the CL program or procedure provides better performance at run time than the processing of several separate commands.
CL procedures can be used in batch or interactive processing. Certain commands or functions are restricted to either batch or interactive jobs.
CL source statements consist of CL commands. You cannot use all CL commands as CL source statements, and you can use some of them only in CL procedures or OPM programs. You can determine what restrictions you want placed on the use of CL commands. You can do this by checking the box in the upper right-hand corner of the syntax diagram of a command. An example that uses the Program (PGM) command is shown below:
1 A maximum of 40 repetitions.
2 All parameters preceding this point can be specified positionally.
The Pgm: B,I in the syntax diagram for the PGM command shows that this command can be used in either batch or interactive jobs, but can be used only within a CL program or procedure.
The commands that you can use only as source statements in CL programs and procedures will have Pgm: in the box. If the box does not contain this indicator, you cannot use the command as source for a CL program or procedure. IBM has online information about how to read a syntax diagram.
CL source statements can be entered in a database source member either interactively from a work station or in a batch job input stream from a device. To create a program using CL source statements, you must enter the source statements into a database source member. You can then create an ILE program by compiling the source member into a module and binding the module into a program object.
CL procedures can be written for many purposes, including:
- To control the sequence of processing and calling of other programs or procedures.
- To display a menu and run commands based on options selected from that menu. This makes the work station user’s job easier and reduces errors.
- To read a database file.
- To handle error conditions issued from commands, programs or procedures, by monitoring for specific messages.
- To control the operation of an application by establishing variables used in the application, such as date, time, and external indicators.
- To provide predefined functions for the system operator, such as starting a subsystem or saving files. This reduces the number of commands the operator uses regularly, and it ensures that system operations are performed consistently.
There are many advantages in using CL procedures for an application. For example:
- Because the commands are stored in a form that can be processed when the program is created, using programs is faster than entering and running the commands individually.
- CL procedures are flexible. Parameters can be passed to CL procedures to adapt the operations performed by the procedure to the requirements of a particular use.
- CL procedures can be tested and debugged like other high-level language programs and procedures.
- CL procedures and programs can incorporate conditional logic and special functions not available when commands are entered individually.
- CL procedures can be bound with procedures of other languages.
You cannot use CL procedures to:
- Add or update records in database files.
- Use printer or ICF files.
- Use sub files within display files.
- Use program-described display files.
Parts of a CL Procedure
While each source statement entered as part of a CL procedure is actually a CL command, the source can be divided into the following basic parts used in many typical CL procedures.
Optional PGM command beginning the procedure and identifying any parameters received.
Mandatory declaration of procedure variables when variables are used. The declare commands must precede all other commands except the PGM command.
CL processing commands
CHGVAR, SNDPGMMSG, OVRDBF, DLTF, …
CL commands used as source statements to manipulate constants or variables (this is a partial list).
Logic control commands
IF, THEN, ELSE, DO, ENDDO, GOTO
Commands used to control processing within the CL procedure.
%SUBSTRING (%SST), %SWITCH, and %BINARY (%BIN)
Built-in functions and operators used in arithmetic, relational or logical expressions.
Program control commands
CL commands used to pass control to other programs.
Procedure control commands
CL commands used to pass control to other procedures.
Optional End Program command.
The sequence, combination, and extent of these components are determined by the logic and design of your application.
Reference : OS/400 CL Programming V5R2
- AS400 Control Language (as400iseries.wordpress.com)
The AS/400 Control Language (CL) is a scripting language for the IBM AS/400 midrange platform bearing a resemblance to the IBM Job Control Language and consisting of an ever-expanding set of command objects (*CMD) used to invoke traditional AS/400 programs and/or get help on what those programs do. CL can also be used to create CL programs (congruent to shell scripts) where there are additional commands that provide program-like functionality (GOTO, IF/ELSE, variable declaration, file input, etc.)
The vast majority of AS/400 commands were written by IBM developers to perform system level tasks like compiling programs, backing up data, changing system configurations, displaying system object details, or deleting them. Commands are not limited to systems level concerns and can be drafted for user applications as well.
Made up of three-character words
Control Language (CL), an integral part of OS/400, is a set of commands by which users control operations and request system-related functions on the AS/400. A CL command usually is made up of three-character words; up to 10 characters (usually three words) can be merged together to form commands. For example, in CL, work is abbreviated as WRK, system is abbreviated as SYS, and status is abbreviated as STS. The command WRKSYSSTS, therefore, is translated as Work with the System Status. CL commands can be entered on the command line or executed from within a program. When commands are entered via a program or menu, the user selects options that are displayed in more friendly, English-type format. The program then translates the selected option into the appropriate CL command or commands.
The conventions for naming the combination verb and object commands are as follows:
The primary convention (as just shown) is to use three letters from each word in the descriptive command name to form the abbreviated command name that is recognized by the system.
The secondary convention is to use single letters from the ending word or words in the command title for the end of the command name, such as the three single letters DLO on the DLTDLO (Delete Document Library Object) command.
An occasional convention is to use single letters in the middle of the command name (usually between commonly used three-character verbs and objects), such as the letters CL in the CRTCLPGM (Create CL Program) command.
Some command names consist of the verb only, such as the MOV (Move) command, or an object only, such as the DATA (Data) command.
The AS/400 is a popular family of mid-sized computer systems which can also be used as multiuser computer systems. By this, we mean that a single computer can interact with more than one user at a time. It was first introduced byon June 21st, 1988.
The AS/400 can be utilized for different business facets. Some models are designed as systems that provide resources to other computers, also known as a “server” in a network of computers, while others are set up for use with terminals or “display stations”. OS400 is the operating system for the AS/400. The AS/400 computers offer more compatibility across the product line than the earlier System/3X computers. Hence, the earlier IBM models of the System/36 and System/38 have since been replaced by the AS/400 systems.
IBM has sold over 600,000 AS/400’s and over 350,000 of them are still active. From distribution warehouses to hospital administrators, and even manufacturing companies, the AS/400 is a strong component in aiding these companies’ daily business operations. The AS/400 utilizes a green screen interface, a built in database that resembles DB2, and a vast array of software to provide business solutions for today’s business needs.
In October of 2000, IBM rebranded the AS/400 and announced its name as theiSeries. As part of IBM’s Systems branding initiative in 2006, it was again renamed to System i. The codename of the AS/400 project was “Silver Lake”, named for the lake in downtown , where development of the system took place.
In April 2008, IBM announced its integration with the System p platform. The unified product line is called IBMand features support for the IBM i (previously known as i5/OS or OS/400), AIX and GNU/Linux operating systems.
It include an integrated DB2 database management system, a menu-driven interface, multi-user support, non-programmable terminals (IBM 5250) and printers, security, communications, client–server and web-based applications. Much of the software necessary to run the IBM System i is included and integrated into the base operating system.
The IBM System i also supports common client–server systems such as ODBC and JDBC for accessing its database from client software such as Java,and others.
Programming languages available for the AS/400 include RPG, assembly language, C, C++, Pascal, Java, EGL, Perl, Smalltalk, COBOL, SQL, BASIC, PHP, PL/I, Python and REXX. Severalare available: AllFusion Plex (see *Plex Wiki), Accelerator for IBM i, ADELIA, Synon, AS/SET, IBM Rational Business Developer Extension, LANSA, ProGen Plus and .
The ILE (Integrated Language Environment) programming environment allows programs from ILE compatible languages (C, C++, COBOL, RPG, Fortran, and CL), to be bound into the same executable and call procedures written in any of the other ILE languages.
The IBM System i fully supports the, including a 32-bit (JVM) and a 64-bit JVM.