Re: Service programs -- MIDRANGE-L

Reminds me of a EAV “Entity-Attribute-Value” table in an RDBMS instead of a
set of relational tables....usually a bad, bad idea.

Problem I have with this is you're throwing away the compile time type
checking; in addition to only allowing the equivalent of "passed by value"
parameters.

Additionally, when I want to call listItems(), I have no way of telling
from within RDi what params are required or even needed.

I don't see where it helps with adding parms either. I can easily add a
parm to an existing proc as *NOPASS:*OMIT and not have to worry about
existing callers.

The design works ok in your MailTool product, but your really only setting
parms for one procedure, SendMail().

Personally, I'd have used a NewMail() with a basic set of required &
optional parameters. Then have additional procs like your
#mailtool_addAttachment() to set the more uncommon parms.

NewMail('charles@xxxxxxxxxxxx':*OMIT
:'somebody@xxxxxxxxxxxxx':*OMIT
:'Re: Hello'
:'Hi There!'
);
addBCCRecipient('boss@xxxxxxxxxxxx');
SendMail();

Charles

On Tue, May 16, 2017 at 6:47 AM, Bradley Stone <bvstone@xxxxxxxxx> wrote:

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
--
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