• 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
    WorksRight Software

    Do you need area code information?
    Do you need ZIP Code information?
    Do you need ZIP+4 information?
    Do you need city name information?
    Do you need county information?
    Do you need a nearest dealer locator system?

    We can HELP! We have affordable AS/400 software and data to do all of the above. Whether you need a simple city name retrieval system or a sophisticated CASS postal coding system, we have it for you!

    The ZIP/CITY system is based on 5-digit ZIP Codes. You can retrieve city names, state names, county names, area codes, time zones, latitude, longitude, and more just by knowing the ZIP Code. We supply information on all the latest area code changes. A nearest dealer locator function is also included. ZIP/CITY includes software, data, monthly updates, and unlimited support. The cost is $495 per year.

    PER/ZIP4 is a sophisticated CASS certified postal coding system for assigning ZIP Codes, ZIP+4, carrier route, and delivery point codes. PER/ZIP4 also provides county names and FIPS codes. PER/ZIP4 can be used interactively, in batch, and with callable programs. PER/ZIP4 includes software, data, monthly updates, and unlimited support. The cost is $3,900 for the first year, and $1,950 for renewal.

    Just call us and we’ll arrange for 30 days FREE use of either ZIP/CITY or PER/ZIP4.

    WorksRight Software, Inc.
    Phone: 601-856-8337
    Fax: 601-856-9432
    Email: software@worksright.com
    Website: www.worksright.com

    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

  • IBM Tweaks Some Power Systems Prices Down, Others Up
  • Disaster Recovery: From OS/400 V5R3 To IBM i 7.4 In 36 Hours
  • The Disconnect In Modernization Planning And Execution
  • Superior Support: One Of The Reasons You Pay The Power Systems Premium
  • IBM i PTF Guide, Volume 25, Number 13
  • IBM i Has a Future ‘If Kept Up To Date,’ IDC Says
  • When You Need Us, We Are Ready To Do Grunt Work
  • Generative AI: Coming to an ERP Near You
  • Four Hundred Monitor, March 22
  • IBM i PTF Guide, Volume 25, Number 12

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 © 2023 IT Jungle