Guru: Why And How Not to Use The Aretha Franklin I/O Method

March 4, 2019 Ted Holt

The Aretha Franklin I/O Method is still used heavily in RPG shops even though a better method has existed for decades. In the following paragraphs, I explain the Aretha Franklin I/O Method, tell you why you should not use it, and show you the superior method.

First, let me give credit where credit is due. Although I had been using the Aretha Franklin I/O Method since my System/34 days, I never knew it by that name. Then Dan Cruikshank (now retired) of IBM informed me of this terminology. Here’s how it works:

Assume an RPG program that needs data from several indexed database files. How does you accomplish that? Simple. You sequentially READ one file and CHAIN, CHAIN, CHAIN to get the data from the other files.

Let’s take a simple example. Suppose you work in a factory and an accounting person whom you serve needs a program that will show them what the customers have on order with us. You need data from four files:

• The order detail file, AGSALESD, has one record for each item the customers have ordered.
• The order header file, AGSALESH, has one record for each customer order. We need this file in order to retrieve the date an order is due to ship.
• The customer master file, AGCUST, has one record for each customer. We need this file in order to retrieve a customer’s name.
• The item master file, AGITEMS, has one record for each item we sell. We need this file in order to retrieve the cost and description of an item.

Here is the code to retrieve this information using the Aretha Franklin I/O Method.

Fagsalesd  if   e           k disk
Fagsalesh  if   e           k disk
Fagcust    if   e           k disk
Fagitems   if   e           k disk

   read detail;
   chain (OrderID) header;
   chain (ItemID)  item;
   chain (CustID)  cust;

Great. It does its job. However, it has its shortcomings. Here are two that come to mind:

1. What if the user asks you to change the sort order? If the new sort field is (fields are) in the order detail file, no problem. You can read an appropriately-keyed logical file or use Open Query File (OPNQRYF). But what if the new sort field is (fields are) in another file? What if the sort fields are in two or more files?
2. What if your shop changes the definition of a field that you’re not even using in this program or adds a new field to a physical file? To avoid a level check, you have to recompile all the programs that use the file in which that field is found.

I much prefer to use SQL. It allows me to join the files, presenting all the necessary fields as if they were stored in one record format.

select d.OrderID, h.Date, d.ItemID, 
       c.Name, i.Cost, i.Description
  from agsalesd as d
  left join agsalesh as h on d.OrderID = h.OrderID
  left join agcust   as c on h.CustID  = c.CustID
  left join agitems  as i on d.ItemID  = i.ItemID
 order by d.OrderID, d.LineNumber

If someone asks me to change the sort order, I reply “no problem,” and modify the ORDER BY clause.

select . . . order by c.Name, d.ItemID

If a file definition changes, and none of the changes are to fields that I use in this program, I don’t do anything to this code. I don’t even have to recompile.

Whatever you do, DO NOT implement the Aretha Franklin I/O Method in SQL, as seen below:

Ted wouldn’t say you should never use the Aretha Franklin I/O Method, but he would prefer you didn’t.

I won’t say that you should never use the Aretha Franklin Method, but that’s only because I avoid the words always and never. Maybe there are situations where CHAIN, CHAIN, CHAIN beats a join with SQL. If so, I don’t know what they would be.

All I know is that I’ve given up the Aretha Franklin I/O Method, and I advise you to do the same. It’s OK. Aretha wouldn’t mind.