• The Four Hundred
  • Subscribe
  • Media Kit
  • Contributors
  • About Us
  • Contact
Menu
  • The Four Hundred
  • Subscribe
  • Media Kit
  • Contributors
  • About Us
  • Contact
  • 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.

    RELATED STORIES

    Returning a Pointer to a Data Structure from a Function

    Functions Can Modify Parameters, Too



                         Post this story to del.icio.us
                   Post this story to Digg
        Post this story to Slashdot

    Share this:

    • Reddit
    • Facebook
    • LinkedIn
    • Twitter
    • Email

    Tags:

    Sponsored by
    Rocket Software

    Unlock the full potential of your data with Rocket Software. Our scalable solutions deliver AI-driven insights, seamless integration, and advanced compliance tools to transform your business. Discover how you can simplify data management, boost efficiency, and drive informed decisions.

    Learn more today.

    Share this:

    • Reddit
    • Facebook
    • LinkedIn
    • Twitter
    • Email

    Sponsored Links

    PowerTech:  Schedule a FREE IBM i Compliance Assessment!
    Vision Solutions:  The State of Resilience 2010. Download the report now!
    Four Hundred Monitor Calendar:  Latest info on national conferences, local events, & Webinars

    IT Jungle Store Top Book Picks

    BACK IN STOCK: Easy Steps to Internet Programming for System i: List Price, $49.95

    The iSeries Express Web Implementer's Guide: List Price, $49.95
    The iSeries Pocket Database Guide: List Price, $59
    The iSeries Pocket SQL Guide: List Price, $59
    The iSeries Pocket WebFacing Primer: List Price, $39
    Migrating to WebSphere Express for iSeries: List Price, $49
    Getting Started with WebSphere Express for iSeries: List Price, $49
    The All-Everything Operating System: List Price, $35
    The Best Joomla! Tutorial Ever!: List Price, $19.95

    MVP Adds Job Library to Scheduler IBM Kills Off Remaining Power6 and Power6+ Systems

    Leave a Reply Cancel reply

Volume 11, Number 5 -- February 2, 2011
THIS ISSUE SPONSORED BY:

Botz & Associates, Inc.
SEQUEL Software
System i Developer

Table of Contents

  • Synchronize Your Outlook Calendar with DB2 for i ERP Data
  • Another Reason Why Function Subprocedures Should Not Modify Their Parameters
  • Admin Alert: QPWDRULES Rules!!! Opening Up User Password Options with i 6.1

Content archive

  • The Four Hundred
  • Four Hundred Stuff
  • Four Hundred Guru

Recent Posts

  • Meet The Next Gen Of IBMers Helping To Build IBM i
  • Looks Like IBM Is Building A Linux-Like PASE For IBM i After All
  • Will Independent IBM i Clouds Survive PowerVS?
  • Now, IBM Is Jacking Up Hardware Maintenance Prices
  • IBM i PTF Guide, Volume 27, Number 24
  • Big Blue Raises IBM i License Transfer Fees, Other Prices
  • Keep The IBM i Youth Movement Going With More Training, Better Tools
  • Remain Begins Migrating DevOps Tools To VS Code
  • IBM Readies LTO-10 Tape Drives And Libraries
  • IBM i PTF Guide, Volume 27, Number 23

Subscribe

To get news from IT Jungle sent to your inbox every week, subscribe to our newsletter.

Pages

  • About Us
  • Contact
  • Contributors
  • Four Hundred Monitor
  • IBM i PTF Guide
  • Media Kit
  • Subscribe

Search

Copyright © 2025 IT Jungle