Now, we'll take the concept to the next level by using prototyped subprocedures.

In a previous article, we explored how nested data structures can help to emulate the way object-oriented programming languages access information. This time, I'd like to take the concept a step further by illustrating how to extend the object-oriented concept within ILE RPG by creating prototyped subprocedures that return nested data structures to the calling program. 

First, the Data

This concept is best illustrated using a data set that's probably something similar to what you work with every day, which is basic customer order data. The table below contains a list of tables that will be used in our example:

This data includes header-level information such as an order number, an order date, and customer bill-to and ship-to information. This would also include detail information such as item numbers, quantity ordered, and unit price information. In addition to that, you may also have order notes at both the header and detail levels. Figure 1 contains a graphical representation of how the data in each of these tables is related. 

Figure 1: This example illustrates how our data is organized.

To get the full view of how the data works, see the table below for a breakdown of the file layouts for each of our sample tables.

Note that each of the tables can be related to one another by the order number, and in the case of the detail records, the order number and line number.

And Then the Code

Using current programming concepts, your programs probably access each of these files using CHAIN and/or SETLL/READE operations, like the example shown here:

...

/free

    Chain OrdKy OrdHdr;

    if %found;

      Setll OrdKy OrdDtl;

      Reade OrdKy OrdDtl;

      Dow not %eof(OrdDtl);

        // detail line processing

         Setll ordlnky dtNotes;

         Reade Ordlnky dtNotes;

          Dow not %eof(dtNotes);

              // detail notes processing

              Reade Ordlnky dtNotes;

            Enddo;

        Reade OrdKy OrdDtl;

      Enddo;

      Setll ordlnky dtNotes;

      Reade Ordlnky dtNotes;

        Dow not %eof(dtNotes);

         // header notes processing

        Reade Ordlnky dtNotes;

       Enddo;

    Endif;

/end-free

...     

This example uses some pretty standard RPG concepts to read the data from the order tables and perform additional processing. 

Wouldn't it be nice, though, to be able to deal with all of the components of your order data using a single object? This can really make your programming tasks much easier because any program that needs to access this same information can utilize a single object that will handle all of the data access for you. 

Implementing the "object-oriented" subprocedures that we're discussing here is really as simple as encapsulating the data access code, like that shown above, into a single service program. These subprocedures can then be called from any programs that need access to that data. For purposes of our example, let's imagine that we would create two subprocedures. 

• GetOrder(orderNumber) retrieves the order data for the supplied order.
• PutOrder(order_DS) creates or updates an order using the supplied data.

The GetOrder subprocedure returns a nested data structure that contains header- and detail-level data from all of our order tables using the standard RPG techniques described earlier, but it returns this data to the caller in a single step through the nested data structures shown below.

dOrdData          DS                  Qualified                        

d  Number                        8  0                                   

d  CreateDate                     d                                    

d  ShipDate                       d                                    

d  Value                        15  5                                  

d  LineCount                     5  0                                  

d  Status                        1a                                    

d  BillTo                             likeds(CustomerDS)               

d  ShipTo                             likeds(CustomerDS)               

d  Notes                              likeds(NotesDS) dim(10)          

d  Line                               likeds(OrdDtl) dim(99)           

dOrdDtl           DS                  Qualified                        

d ItemNumber                    15a                                    

d ItemDesc                      50a                                    

d OrderQuantity                 15  5    

d ShipQuantity                  15  5                                  

d UnitPrice                     15  5                                  

d LineValue                     15  5                                  

d LineStatus                     1a                                     

d Notes                               likeds(NotesDS) dim(10)          

dCustomerDS       DS                  Qualified                        

d Number                         8  0                                  

d Name                          35a                                    

d Address                       35a                         

d City                          20a                          

d State                          2a                         

d ZipCode                       10a                         

d PhoneNumber                   10a                         

dNotesDS          DS                  Qualified             

d Text                          50           
                                                                                    

Notice that we've actually defined four data structures here. Three of these exist simply to be nested within the OrdData structure, which will be returned as the result of the GetOrder subprocedure. The OrdDtl data structure defines the fields that relate to the order lines. The LineValue field here is a calculated field based on the order quantity multiplied by the unit price. You'll also notice that this structure also contains a "likeds" for the NotesDS data structure, which contains note details. 

By including the dim(10) keyword, we identify that each order line can have up to 10 note lines. This same data structure is included in the OrdData data structure to store the order header note data.

We include two copies of the CustomerDS data structure. These will be used to return bill-to and ship-to customer data. Note that the name and address fields are not part of the data we defined earlier. These fields, along with the ItemDesc field on the order detail data structure, are retrieved from master files.  This means that when all is said and done, our subprocedure is actually returning data from at least six database tables in a single statement.

We also include several other calculated fields, including the line count and order value fields.

Note that each of our statements includes the "Qualified" keyword to indicate that all access to the fields contained within that data structure needs to be specified in a fully qualified manner.   

To associate our newly defined OrdData structure with the GetOrder subprocedure, we use the following prototype:

dGetOrder         PR                  likeds(OrdData)

d OrderNumber                8  0       

The likeds keyword identifies that the value returned by this subprocedure should mimic the OrdData data structure.   

The result is that, within a program that utilizes the GetOrder subprocedure, we can load all of our order data in a single statement, as shown below:

 /free

    Order = GetOrder(OrdNum);

 /end-free

In this example, the Order variable would first be defined as a data structure with the likeds(OrdData) keyword on the data structure definition. Once that's done, after calling the GetOrder subprocedure, we can access the order data using the variables shown below:

order.number          

order.orderdate       

order.value           

order.shipdate        

order.billto.number   

order.billto.name     

order.billto.address  

order.billto.city     

order.billto.state    

order.billto.zipcode  

order.shipto.number   

order.shipto.name     

order.shipto.address  

order.shipto.city     

order.shipto.state    

order.shipto.zipcode  

order.linecount

order.notes(x).text

order.lines(x).itemnumber

order.lines(x).OrderQuantity

order.lines(x).ShipQuantity

order.lines(x).UnitPrice

order.lines(x).ItemDesc

order.lines(x).LineValue

order.lines(x).notes(y).text

Each order line and/or note line can be accessed by providing a value within the parentheses that reflects the line number and/or sequence number related to the specific detail line or note sequence to be retrieved.

Similarly, the PutOrder subprocedure is used to create the data in all of these tables. The difference here is that we provide the OrdData data structure as the input parameter to the subprocedure and allow the subprocedure to disassemble the order data and create/update records in each of the database tables. Below is an example of how this subprocedure would be called to create a new order: 

dNewOrder         DS                  likeds(OrdData)

/free

    Clear NewOrder;

    NewOrder.BillTo.Number = 12345;

    NewOrder.ShipTo.Number = 12346;

    NewOrder.LineCount = 1;

    NewOrder.Line(1).ItemNumber = 'ABC123';

    NewOrder.Line(1).OrderQuantity = 24;

    NewOrder.Line(1).UnitPrice = 9.95;

    NewOrder.Line(1).Notes(1).Text = 'Ship this item right away!';

    PutOrder(NewOrder);

 /end-free

In this example, we define our data structure NewOrder to be a copy of the OrdData data structure. We start by clearing this new data structure, and then we populate the required data. Remember that we assume that the PutOrder subprocedure will contain all of the logic to determine whether this is an existing order or a new order and to react accordingly in each circumstance.

Note that this routine would also need to have data validation logic built in to verify that the data provided was valid and followed business rules.

Below is another example that shows how the GetOrder and PutOrder subprocedures might be combined to update an existing order by adding a line:

D Order           DS                  likeds(OrdData)

/free

    Order = GetData(OrdNum);

    Order.Line(LineCount + 1).ItemNumber = NewItem;

    Order.Line(LineCount + 1).OrderQuantity = NewQty;

    Order.Line(LineCount + 1).UnitPrice = ItemPrice;

    PutOrder(Order);

 /end-free

Again, this example assumes that the PutOrder subprocedure will include logic to realize that this is an existing order (probably based on the fact that our data structure includes an order number). It then updates that order rather than create a new one. 

Finally...the Fine Print

The biggest caveat when implementing this concept is the 65535 character limitation for a data structure. Since ultimately an RPG data structure is handled like a giant character field, you can only define a data structure whose largest possible size (including all possible array elements) is no more than 65535 characters. In the case of our example OrdData data structure, we are just under that limitation at 62763 characters. That issue aside, utilizing this concept can completely change the way you write applications by changing from a "data file-centric" approach to an object-oriented approach to how your applications access data.