× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Doesn't this force you into a global variable situation? How do you handle multiple procedures in the same service program? Seems like you could have issues with managing global variables, and left over values. At this point you might as well just go back to using subroutines.

Mark Murphy
Atlas Data Systems
mmurphy@xxxxxxxxxxxxxxx


-----Bradley Stone <bvstone@xxxxxxxxx> wrote: -----
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
From: Bradley Stone <bvstone@xxxxxxxxx>
Date: 05/16/2017 08:47AM
Subject: Re: Service programs


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

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.