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)
AS400 jobs can originate from several sources and are classified by how they originate on the system. In this course, and in general, you will deal mostly with two types of jobs: interactive and batch.
An interactive job begins when a user signs on to an AS400 and it terminates when the user sign off the AS400 or the job is ended. Interactive jobs run in conversational mode, which means there is a dialogue of sorts between the user and the program, utility or operating system function. Because of this conversational, back-and-forth nature of interactive jobs, any CPU-or I/O-intensive request a user makes could lock up the workstation keyboard until the request is completed. Therefore, it is often advisable to direct such requests to a subsystem designed to handle them. That is, to submit them as batch jobs.
Batch jobs can execute without user interaction; they do not require data or controlling values to be input through the workstation once they have started. Batch jobs are sent to a job queue until they can begin execution. A job queue is a staging area, managed by the subsystem in which the job will run, where batch jobs wait in line for their turn at processing. Each batch subsystem can execute only a limited number of batch jobs concurrently. If no other higher-priority jobs are waiting, a batch job can start right away; otherwise, it must wait its turn. Batch jobs may also be held until a certain time of day. For example, a given batch job may be automatically run each night at 11:00 p.m. An example of such a batch job would be the nightly deletion of work files before a system backup.