Another Reason Why Function Subprocedures Should Not Modify Their Parameters

February 2, 2011 Ted Holt

I’ve never liked the idea of functions modifying their parameters. It seems to me that a function should accept zero or more input values and return one and only one value. Modifying a parameter is a roundabout way of returning another value. While looking for something in the ILE RPG reference recently, I found yet one more reason why it’s not a good idea for a function to modify a parm.

This is IBM‘s example code with my modifications to make it run.

Figure 189. Sample coding of a call with side effects 
 *..1....+....2....+....3....+....4....+....5....+....6....+....7...+....
H dftactgrp(*no) actgrp(*new)

D fn              PR             5P 0
D   parm                         5P 0

D A               S              5P 0
D X               S              5P 0

 *   A is a variable.  FN is procedure that modifies A.
 /free
     *inlr = *on;   
     a = 5;
     x = a + fn(a);
     return;
 /end-free
 
P fn              B
D fn              PI             5P 0
D   parm                         5P 0
 /free
     parm = parm + 1;
     return  2 * parm;
 /end-free
P fn              E

What’s the value of X after the second EVAL?

The answer is: “I don’t know.” The answer may be 17 or 18, depending on whether the system calls the function before adding, or adds before calling the function. In IBM’s words, “The order of evaluation within an expression is not guaranteed.”

Little errors like this cause debugging nightmares. So what’s the solution?

The solution is to return all values in modified parameters, like this:

H dftactgrp(*no) actgrp(*new)

D proc            PR
D   parm                         5P 0
D   answer                       5P 0

D A               S              5P 0
D X               S              5P 0

 *   A is a variable.  PROC is procedure that modifies A.
 /free
     *inlr = *on;
     a = 5;
     proc (a: x);
     x += a;
     return;
 /end-free

P proc            B
D proc            PI
D   parm                         5P 0
D   answer                       5P 0
 /free
     parm = parm + 1;
     answer = 2 * parm;
 /end-free
P proc            E

Now let’s make it a bit more practical. Why would anybody make a function subprocedure modify a parameter? Maybe out of scope creep.

Suppose the original function takes a customer number and date as arguments and returns the total amount of sales for that customer on that date.

DCustSalesForDay  pr             9p 2
D   CustNbr                      6p 0 const
D   Date                         8p 0 const

D TotalSales      s              9P 2

/free
     // call the function subprocedure
     TotalSales = CustSalesForDay (CusNbr: DateOfSale);

... etc ...

PCustSalesForDay  b
D                 pi             9p 2
D   CustNbr                      6p 0 const
D   Date                         8p 0 const
D*** locals
D TotSls          s              9p 2
 /free
     setll (CustNbr: Date) slshistr;
     dow '1';
        reade (CustNbr: Date) slshistr;
        if %eof();
           leave;
        endif;
        TotSls += InvAmt;
     enddo;
     return TotSls;
 /end-free
P                 E

Later, someone requests that the number of sales also be printed on the report. Since we already have a routine that’s accessing those database records, we may as well add another parameter for the count.

DCustSalesForDay  pr             9p 2
D   CustNbr                      6p 0 const
D   Date                         8p 0 const
D   NbrOfSales                   3P 0

D TotalSales      s              9P 2
D SalesCount      s              3P 0

/free
     TotalSales = CustSalesForDay (CusNbr: DateOfSale: SalesCount);

... etc ...
PCustSalesForDay  b
D                 pi             9p 2
D   CustNbr                      6p 0 const
D   Date                         8p 0 const
D   NbrOfSls                     3P 0
D*** locals
D TotSls          s              9p 2
 /free
     TotSls = *zero;
     NbrOfSls = *zero;
     setll (CustNbr: Date) slshistr;
     dow '1';
        reade (CustNbr: Date) slshistr;
        if %eof();
           leave;
        endif;
        TotSls += InvAmt;
        NbrOfSls += 1;
     enddo;
     return TotSls;
 /end-free
P                 E

But here’s the better way:

DCustSalesForDay  pr
D   CustNbr                      6p 0 const
D   Date                         8p 0 const
D   AmtOfSales                   9P 2
D   NbrOfSales                   3P 0

D TotalSales      s              9P 2
D SalesCount      s              3P 0

/free
     CustSalesForDay (CusNbr: DateOfSale: TotalSales: SalesCount);

... etc ...
PCustSalesForDay  b
D                 pi
D   CustNbr                      6p 0 const
D   Date                         8p 0 const
D   AmtOfSales                   9P 2
D   NbrOfSales                   3P 0
 /free
     AmtOfSales = *zero;
     NbrOfSales = *zero;
     setll (CustNbr: Date) slshistr;
     dow '1';
        reade (CustNbr: Date) slshistr;
        if %eof();
           leave;
        endif;
        AmtOfSales += InvAmt;
        NbrOfSales += 1;
     enddo;
 /end-free
P                 E

There are exceptions to this principle. For example, we’ve published two articles dealing with I/O routines that return one value and modify another. I’ve referenced them below.

To see the RPG manual page that gave rise to this tip, visit the IBM i Information Center.