If there are many caller programs that need the total, then having total calculated within the caller program does not sound like a good idea for me. Your requirement is to provide a functions that returns a total plus all the tax details. That does not mean that you can't break this requirement into several small functions. For example, you could create a function call getTaxDetail() and create another function call getTaxTotal(). getTaxTotal basically calls getTaxDetail() and adds up the detail to get the total and returns it to the caller. To make it even more flexible, you could add tax-detail MODS as optional parameters in getTaxTotal. This way, caller that only needs tax detail can simply call getTaxDetail(). Caller that only needs tax Total can simply call the getTaxTotal() without passing the optional params. Caller that needs total & detail can simply call the getTaxTotal with the optional param.
HTH.
"David FOXWELL" <David.FOXWELL@xxxxxxxxx> wrote in message news:<mailman.3033.1224506316.30674.rpg400-l@xxxxxxxxxxxx>...
Hi Vern,
Well firstly, although perhaps not so important, I don't see why the function would calculate a total. Surely it should be returning a tax rate so that the caller would do that calculation. Then when I see type tax I wonder what else concerning the tax in the future will be needed. Already thinking of all those parameters in all those programs that would have to be updated. Shouldn't the function be able to access all the taxes for one product and for each call to another function be able to return the tax rate for the next tax?
It will be in ILE. The RPGIII will have to use a wrapper. These are big, old programs that aren't about to be rewritten yet get modified as often as the newer ILE stuff.
-----Message d'origine-----
De : rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] De la part de Vern Hamberg
Envoyé : lundi 20 octobre 2008 13:58
À : RPG programming on the AS400 / iSeries
Objet : Re: function with a bunch of parameters
David
Alan's comment included the problem of many parameters that change a lot
- not just many parameters. There's really nothing wrong with having several parameters to pass the information you need in the procedure or program being called.
You also are limited by all those RPGIII programs - which are probably not going to change anytime soon. So you cannot return values - everything has to be in parameters. Wait - if this is a new program, don't the consuming programs have to be changed, as well? Are you restricted to using RPGIII? Can you go to ILE?
Hope my questions are on point - good luck Vern
David FOXWELL wrote:
Hi all,
When I first discovered this list, I started a discussion that made Alan Campin's stomach turn. It was remembering these last two words that helped me refind the discussion in the archives.
I was particularly impressed by Alan's response here :
http://archive.midrange.com/rpg400-l/200706/msg00363.html
I've kept that in mind ever since and I'm sure that my programs have improved because of this approach. However, I've just been given a function to write where the parameters are already given for me. Alarm bells are ringing.
Here's my list of parameters
Input
Product code
Date (to see if the tax was applied at that time )
Cost before taxes
Output
Cost with all taxes applied
Total of all different taxes
MODS details of each tax applied:
Tax code
Tax type
Tax rate (%)
Tax total (EUR)
I'd be interested to know how you'd go about reducing the size of this bunch of parameters. A lot of RPG400 will need this information.
--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.
----------
midrange.com
