What do you get when you combine nested data structures with prototyped subprocedures?

According to Wikipedia, although the concepts behind object-oriented (OO) programming have been around since the 1960s, they weren't part of commonly used languages until the 1990s. At its most basic level, OO programming allows a programmer to work with objects in a hierarchical structure, so anything associated with a given "object" can be found within that object's structure. This article explores how to combine nested qualified data structures with prototyped subprocedures to achieve OO-like functionality in ILE RPG.

Qualified Nested Data Structures

Qualified data structures, first introduced with V5R1, allow you to refer to the subfields of a given data structure by using a dotted notation similar to that used within languages like C++ and Java. Below is an example of a qualified data structure.

D objectData  Ds                  Qualified

D   Height                   5  0

D   Width                    5  0

D   Color                   15

Note that our data structure named objectData contains three subfields: Height, Width, and Color. When referencing any of these fields within a program, we reference the subfields using the data structure name as a qualifying prefix:

 /Free

      Dsply objectData.Color;

      Area = objectData.Height * objectData.Width;

 /End-free

While your initial reaction may be that this is just additional typing that you'll have to do every time you reference those fields, there is a huge benefit to using qualified data structures. Not least of these is that there will be no ambiguity about what field you are referring to. The real power of qualified data structures comes when you utilize multiple copies of the same data structure within a program via the LIKEDS keyword. This keyword gives you the ability to create a data structure that is a "copy" of another data structure.

D object2     Ds                  likeds(objectData)

This new data structure contains its own copy of all of the subfields as defined on the original data structure. In V5R2, the LIKEDS keyword also gave us the ability to create nested data structures, so now a single data structure can actually encompass multiple levels.

D ingred_DS   Ds                  Qualified

D   Ingredient              30   

D   Amount                   5  0

D   UnitOfMeasure            5

D nutrit_DS   Ds                  Qualified

D   Calories                 5  0

D   Carbs                    5  0

D Recipe      Ds                  Qualified

D   Name                   128A 

D   Servings                 5  0

D   Serving_size             5  0

D   Instructions           512A 

D   Ingredients                   likeds(ingred_DS) dim(50)

D   Nutritional                   likeds(nutrit_DS)

This multi-level approach allows us to define an object structure similar to that used in languages like Java. Note that in our example above, within our Recipe data structure, we identify that the ingred_DS ­­data structure is an array with 50 elements. When referenced within our application, we can refer to individual items within the Recipe object as shown here:

/Free

      Recipe.Name = 'Green Eggs and Ham';

      Recipe.Ingredients(1).Ingredient = 'Eggs';

      Recipe.Ingredients(1).Amount = 2;

      Recipe.Ingredients(2).Ingredient = 'Green Food Coloring';

      Recipe.Ingredients(2).Amount = 1;

      Recipe.Ingredients(2).UnitOfMeasure = 'tsp';

      Recipe.Ingredients(3).Ingredient = 'Ham';

      Recipe.Ingredients(3).Amount = 0.5;

      Recipe.Ingredients(3).UnitOfMeasure = 'cups';

      Recipe.Nutritional.Calories = 250;

      Recepe.Nutritional.Carbs = 0;

      Receipt.Servings = 1;

/End-free

Notice how we are able to refer to individual subfields of each element of our Ingredients collection, as well as refer to subfields of the Nutritional data structure along with the simple value for the Servings property. If we take this concept to the next level, we can one again use the LIKEDS keyword to assign the value of the whole Recipe object to another data structure altogether:

D RecipeCard  Ds                  likeds(Recipe)

...

/Free

      RecipeCard = Recipe;

/End-free

After execution of this command, all of the subfields within the Recipe object will be transferred to the same subfield within the ReceipeCard object. This simple transfer allows us to build our data in a "work" object and transfer it to another object after completion. To extend this concept, we can create an arrayed version of our object to store multiple similar objects, as shown here:

D RecipeBox   Ds                  likeds(Recipe) dim(255)

...

/Free

      cardNumber +=1;

      RecipeBox(cardNumber) = Recipe;

/End-free

This example defines our RecipeBox object as an arrayed data structure with 255 elements. Each element has the same structure as our Recipe data structure. Figure 1 below illustrates how this structure works:

Figure 1: This illustrates how our array object is organized.  (Click image to enlarge.)

As this example shows, what we end up with is something similar to a "collection" within other object-oriented languages (VB, Java, etc.).

While this may not seem very useful within two data structures of a single program, it can become extremely valuable when combined with prototyped procedures within a service program. Next time, we'll explore that concept as well as work with a few useful subprocedure examples that make use of this concept.