What if CL were an object-oriented programming (OOP) language? How would it differ from its present form? My purpose in this article is not to say that CL should be an OOP language. Instead, I explain the basic difference between procedural programming and OOP for those people who have spent years in the former. In doing so, I use CL as a common reference point to which everyone can relate.

I know that procedural programmers are often bewildered when they try to understand OOP. Because its many terms, such as polymorphism, encapsulation, instantiation, and superclass, give the impression that OOP is beyond mere mortals, I avoid all these terms. I hope this approach helps readers grasp the concepts of OOP. After you have an understanding of the concepts, the jargon should come to you more easily.

Object-based and Object-oriented: Common Ground

The AS/400 is an object-based computer. Although object-based and object-oriented are not the same, they are similar. In both cases, each type of object has certain operations that can be performed on it.

For example, one type of object is the data area. CL uses commands like Create Data Area (CRTDTAARA), Delete Data Area (DLTDTAARA), and Change Data Area (CHGDTAARA). Look at the DLTDTAARA command in Figure 1. It deletes a data area called REVISION in a library named ATLANTA. DLTDTAARA has already been designed and coded by people at IBM Rochester. For that command to work properly, you must give it some information (in this case, the name of a data area). Therefore, DLTDTAARA exists separately from the data area objects on the system. When you want to delete a data area, you must think about the command you need to use and then move your thoughts toward the object that you need to work with.

If CL were an OOP language, you wouldn’t have commands like DLTDTAARA. Instead, you would declare objects to be of a certain class (type), and this declaration would give you immediate access to methods (commands) that would let you manipulate the object. As a result, you might declare a CL variable to be of class *DTAARA, as the Declare (DCL) command shows in Figure 2.

However, the DCL command would only create a variable. You would then have to tie the variable to the real data area, using syntax similar to CHGVAR in Figure 2. Execution of these two commands would let you use such methods as CRT, DLT, and CHG to manipulate the data area represented by variable &INFO.

In OO CL, you wouldn’t use DLTDTAARA to delete the REVISION area in the ATLANTA library. You would instead invoke a deletion method like the one in Figure 3. Note that I’ve separated the variable from the method with a period (commonly referred to as a dot operator) and I’ve used the parentheses that follow DLT to show that DLT was a method, not a variable. I’ve chosen the conventions of the dot qualification operator and method parentheses because they are used in C++ and Java.

Consequently, if CL were an OOP language, your thought process would be reversed. You would first think about the data area to be deleted and then move your attention to how to delete it.

Inheritance

Because a data area is a type of object, you can also use commands such as Create Duplicate Object (CRTDUPOBJ) and Move Object (MOVOBJ) to manipulate data areas. If CL were CL++, certain methods would be defined for use with the “object” class. The “object” class would have methods such as Move (MOV), Create Duplicate (CRTDUP), Check (CHK), Compress (CPR), Decompress (DCP), and Edit Authority (EDTAUT). Any of the specific types of objects, such as data areas, data queues, and programs, could use these methods. The code in Figure 4 shows how a variable of the *DTAARA type would use the MOV method of the *OBJECT type.

Getters and Setters

If CL were an OOP language, it would also have getters and setters. A getter is a method that retrieves a value from an object; a setter changes a value in the instance of an object.

First, I should review how to “get” and “set” values when working with objects in CL. To “get” a value from an object usually requires a Retrieve (RTV) command. You can have Retrieve Job Attributes (RTVJOBA), Retrieve Member Description (RTVMBRD), Retrieve Object Description (RTVOBJD), and so on.

To “set” a value, CL usually uses a Change (CHG) command, such as Change Data Area (CHGDTAARA), Change Job (CHGJOB), and Change User Profile (CHGUSRPRF).

Figure 5 shows how to retrieve from and change a data area in CL. However, if CL were an OOP language, you would use RTV and CHG methods instead, as shown in Figure 6. In fact, you might have more than one of each method. For instance, you might have one RTV method that extracts a substring of a data area and another RTV method that extracts the entire data area, as in Figure 7. The compiler would know which of the two methods to invoke by referring to the parameter list.

A Bigger Example

Figure 8 shows a CL program that creates a data queue (if it doesn’t already exist), receives information from a second data queue, changes that information, and sends it to the first data queue. If CL were an OOP language, you might write it as it is written in Figure 9. Again, the primary difference is that the commands begin with the object being manipulated and move from there to the action being taken.

Are There Any Objections?

If you’ve looked at OOP before but were put off by its strange terminology, don’t give up. OOP is logical in design, as is procedural programming, and you can master both.

DLTDTAARA DTAARA(ATLANTA/REVISION)

Figure 1: Use CL’s DLTDTAARA command to delete a data area.

DCL VAR(&INFO) TYPE(*DTAARA)

CHGVAR VAR(&INFO) VALUE(NEW DTAARA('ATLANTA/REVISION'))

Figure 2: OO CL would declare a variable to reference a data area object.

&INFO.DLT( )

Figure 3: Here’s one method you might use to delete a data area in OO CL.

&INFO.MOV(CHARLOTTE)

Figure 4: A data area in OO CL would be able to use methods defined for the *OBJECT type.

RTVDTAARA DTAARA(ATLANTA/REVISION (26 8)) RTNVAR(&OPTION)

CHGDTAARA DTAARA(ATLANTA/REVISION (121 8)) VALUE('CLEANUP')

Figure 5: CL accomplishes “getting and setting” with CHG and RTV commands.

&INFO.RTV((26 8) &OPTION)
&INFO.CHG((121 8) 'CLEANUP')

Figure 6: OO CL would use “getters and setters” to manipulate objects.

&INFO.RTV((26 8) &OPTION)
&INFO.RTV(&PLANTINFO)

Figure 7: Methods of the same name are common in OOP.

&INFO.RTV((26 8) &OPTION)
&INFO.CHG((121 8) 'CLEANUP')

Figure 8: This simple CL program manipulates data queues.

PGM

&PRODDATA.DCL(*CHAR 80) /* production data */

&DTALEN.DCL(*DEC (5 0) 80)

&WAIT.DCL(*DEC (5 0) -1)

&FROMFLOOR.DCL(*DTAQ) /* from shop floor */

&TOPRODCTL.DCL(*DTAQ) /* to production control */

/* Instantiate the variables */

&FROMFLOOR.CHG(NEW DTAQ('*LIBL/FROMSHOP'))

&TOPRODCTL.CHG(NEW DTAQ('*CURLIB/TOPRODCTL'))

/* Create the to-production-control data queue, if it doesn't exist */

&TOPRODCTL.CREATE(*STD 80 *N *FIFO *N +

'send info to production control' *N)

MONMSG CPF0000

/* Receive data from the shop floor */

&FROMFLOOR.RCV(&DTALEN &PRODDATA &WAIT)

/* Change the data */

&PRODDATA.CHG((56 2) '00')

/* Send it to production control */

&TOPRODCTL.SND(&DTALEN &PRODDATA)

IF (&PRODDATA.RTV(1 4) *NE QUIT) THEN(GOTO RCV)

ENDPGM

Figure 9: This fictitious program code illustrates how data queues might be manipulated if CL were an OOP language.