Re: Service programs

[Bradley Stone <bvstone@xxxxxxxxx>]

One thing I like to do is use more generic procedures to set
"parameter" values...  ie:

function_setValue(parameter:value);

ie.
cstmst_setValue('custno':'993043');
cstmst_listOverdueInvoices();

or

inventory_setValue('qtyLessThan':'10')
inventory_setValue('itemType':'parishable');
inventory_listItems();

This way if you need to add parameters you simply update the
<function>_setValue() procedure and add new possible variables to set.
No change in signatures this way.

You could set up constants for the parameter names in the /copy files
for the prototypes to make things easier as well.

Here's some documentation on just one application that I did it with:
http://docs.bvstools.com/home/mailtool/docs/chapter-3/-mailtool_setvalue

Because I've had this in production at many shops I've found it works
great and wish I would have done this before with my other
applications.
Bradley V. Stone
www.bvstools.com
Native IBM i e-Mail solutions for Microsoft Office 365, Gmail, or any
Cloud Provider!


On Tue, May 16, 2017 at 7:29 AM, Bill Reed <breed@xxxxxxxxxxxxxx> wrote:
> While defining lots of parameters can, like anything, be taken to an extreme ("let's see, was that the 25th or 26th yes/no parameter?"), here's an example of how a single sub-procedure with numerous parameters has helped me.  A common request is "I'd like to see customer sales for last year, etc., etc."  The qualifying questions then become:
> 1. Order receipts, or invoiced shipments?
> 2. Gross sales, or net of cash discount?
> 3. Include the big, one-time anomaly orders that are certainly sales, but which skew monthly numbers when considering things like budgets?
> 4. Include the purchased add-on's that we sell with the product, or only the stuff we really make?
> 5. If for a previous year, do you want the whole year, or only comparable year-to-date to match this year?
>
> If each of these answers becomes a parameter, along with customer ID, then I can write this code one time and account for all of the options.  Then any program which needs to retrieve "customer sales," for one or multiple customers, can call the procedure.  Six months (or six years) later, if I'm asked "is this report showing gross or net?" a glance at the call should tell me.  Previously I would have had to read the code in the main program to see whether or not the terms discount was being taken into consideration, etc.  Not to mention that the main program no longer has to deal with defining, opening, and reading the appropriate files -- excuse me, tables -- if I can even remember which ones they're supposed to be.  Also, using named constants as parameters, rather than 0 or 1, or Y or N, can make the call very readable.
>
> And as was mentioned earlier, I can build a User Defined Function over the sub-procedure, with the same parameters, and get a customer sales number -- for any combination of options -- to include in my SQL Select statement.
>
> And as to why a service program rather than a standalone called program:  there will certainly be many other similar functions relating to an application.  Having them together in one service program allows longer, more meaningful procedure names, and only one object which needs to be bound into the program via a /COPY statement.
>
> Bill Reed
> Rock of Ages Corp.
>
>
>
> -----Original Message-----
> From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Booth Martin
> Sent: Monday, May 15, 2017 5:43 PM
> To: Midrange Systems Technical Discussion
> Subject: Re: Service programs
>
> I have a hard time seeing overloaded parameters as a benefit. They strike me as a nerd's playground and an invitation to documentation errors, confusion, and unexpected results in the future.
>
> Also, it looks to me like the same underlying code gets written, whichever solution is chosen.  All that differs is how the code is bundled and delivered.
>
>
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.
>
> Please contact support@xxxxxxxxxxxx for any subscription related questions.
>
> Help support midrange.com by shopping at amazon.com with our affiliate link: http://amzn.to/2dEadiD
>
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>
> Please contact support@xxxxxxxxxxxx for any subscription related questions.
>
> Help support midrange.com by shopping at amazon.com with our affiliate link: http://amzn.to/2dEadiD