INTRODUCTION

Control Language (CL) is a programming language used primarily for control purposes with the IBM i operating system (formerly known as OS/400 and i5/OS). Originating in the early 1980s with the System/38 and continued on the AS/400 eServer iSeries, and System i, CL has undergone a series of improvements (and it still does to this day). While CL is not a general-purpose, high-level language (HLL), its flexibility does allow it to be used for much more than simple control operations. CL is based on commands. All program statements are nothing more than commands. Many of the commands are the same ones you would use manually, from the keyboard, to operate the computer.

WHO NEEDS CL?

CL is for everyone. Because commands can be included in a CL program, you can automate most i5 operations by writing a CL program that contains the necessary commands.

All i5 shops are, by necessity, at least bilingual, because they must support at least two programming languages — and CL is one of them. The other language should be a high-level language such as COBOL or RPG.

WHO HAS CL?

Because CL is part of the computer's operating system (formerly known as i5/OS, but now called IBM i), every system that runs IBM i has CL. Because every system that runs IBM i has CL, it should be the programming language of choice for any programs that do not require the higher functions provided by high-level languages like RPG. This would allow you to take the same program to another i5 with 100 percent certainty that the program will be usable. Such is not the case with other programming languages, such as RPG and COBOL, because most shops install only the compilers they need or wish to use. Yet, CL is absolutely everywhere.

CAPABILITIES OF CL

With CL you can do any of the following:

* Control system power up and power down.

* Change the configuration of the system through changes in system values or line, controller, and device descriptions.

* Manage work on the system by controlling subsystems, job queues, job priorities, memory pools, time slices, and so on.

* Start other jobs by calling programs directly or by submitting jobs to batch processing.

* Control system security by performing security checks or by actually changing user and object authorities.

* Control all forms of communications between your i5 and other systems (peers, hosts, PCs, remote controllers).

* Manage objects in libraries. Objects can be created, duplicated, changed, deleted, reorganized, cleared, renamed, and allocated with CL programs.

The preceding list is not all-inclusive. CL contains more than 1,000 commands with diverse functions.

LIMITATIONS OF CL

As previously noted, CL is not an HLL. CL cannot accomplish everything a language such as RPG can accomplish.

* Database manipulations are limited to reading files. You cannot directly update or write individual records in database files.

* CL supports only five data types: character, decimal, logical, signed integer, and unsigned integer.

A FIRST LOOK AT CL

What better way to begin a study of CL programming than by looking at a typical CL procedure?

THE PARTS OF A CL PROCEDURE

A procedure is a compilable set of CL commands. Dissecting and analyzing the various parts of a CL procedure serve as a good introduction to CL. Figure 2.1 shows a typical CL procedure. The lines that make up a CL procedure can be called CL statements or CL commands. The two terms are interchangeable.

Figure 2.2 illustrates the structure of a typical CL procedure. The sections that follow explain each individual part of the procedure.

The PGM Command

The Program (PGM) command (Figure 2.3) identifies the beginning of the procedure.

The PARM parameter lists the parameters coming into (or going out of) the procedure. The example shown in Figure 2.3 contains only one parameter, called &GREETING, which is a CL variable.

The COPYRIGHT Command

The COPYRIGHT command (Figure 2.4) provides a way to embed copyright information within a CL module. It is optional. If used, the COPYRIGHT command must follow the PGM command, and it must precede the global MONMSG commands and all executable commands.

To view the copyright information, use the Display Module (DSPMOD) command.

The Declarations

Figure 2.5 shows some examples of declaration (DCL) commands.

Each Declare (DCL) command defines a single variable to the CL procedure. All variables must be declared at the beginning of the procedure.

The DCL command has four parameters, but only the first two are required. The first parameter, VAR, names the variable being declared. The second parameter, TYPE, indicates whether it is a character, decimal, unsigned integer, signed integer, or logical variable. The third parameter, LEN, indicates the variable's length. In addition, the fourth parameter, VALUE, gives the variable its initial value.

In Figure 2.5, the parameter keywords VAR, TYPE, and LEN have been omitted to keep the procedure uncluttered. You could also code the DCLs as shown in Figure 2.6.

Also, notice that all variables are the *CHAR (character) type. Besides DCL, the declaration section of the procedure can contain up to five Declare File (DCLF) commands. The examples shown in Figures 2.5 and 2.6 do not include any DCLF commands.

Global MONMSG

Although the Monitor Message (MONMSG) command is described at length in Chapter 6, it deserves a brief mention now. An example is shown in Figure 2.7.

The MONMSG command is used to take corrective action when an error is detected by the system after executing any command in a CL procedure. When MONMSG is coded between the declarations and the body of the procedure, it acts as a global error trap because it remains in effect throughout the execution of the procedure. If placed anywhere else, it applies only to the command that immediately precedes it.

The Body of a Procedure

Figure 2.8 shows an example of the body of a typical CL procedure.

The body of the procedure is where the action takes place. It is the meat and potatoes of the CL procedure. Although the PGM and DCL commands are needed...