I have many issues related to a 30yo home grown relatively complicated system cooked up by a multitude of programmers. The vast majority of the code has been modified in the 30 years, but occasionally I'll find something from '87. How it made it through all the conversions and maintained the date I don't know. Not the issue.
Regarding service program vs binding directory, I know the difference, but not the reality application. This is my problem. I studied Scott K's (and others') excellent guides for writing and implementing procedures. The only experience I have in working with procedure is my own start-from-scratch efforts. And I've been fairly successful in implementing a few. Even some relatively complicated ones. I've been through a couple of conference sessions, one of which was with Jon Paris in Vegas, many moon ago. But while discussed the issue of practical usage with what I deal with has never been done in a working environment with others who are experienced with the pitfalls and how to avoid them.
Plus, I'm working at overcoming a "we did that once and decided it's too complicated" mentality. I'm not in charge. And that's probably a good thing.
And I'm not smarter than anybody. Especially after reading a lot of the emails to midrange lists. As a matter of fact, most emails I can hardly say "why would they ask THAT question?" I'm smart enough to know why they would. But I WAS considering naming my sub-procedures that way. Are you saying you didn't?
duane
-----Original Message-----
From: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Buck Calabro
Sent: Friday, February 03, 2017 12:36 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: Procedure Examples VR7.1
On 2/3/2017 11:54 AM, Duane Scott wrote:
I am curious as to what experiences led up to these rules.
ILE has many options, many choices. That's to enable very sophisticated applications. I don't have a sophisticated application and suspect few do. What's sophisticated? One example: Sharing open data paths where one program does a CHAIN (and no UPDATE) and a different program does an UPDATE (and no CHAIN). Now imagine isolating that so that these same two programs are called twice; in separate activation groups. And you don't want the CHAIN from AG(ACCOUNTING) to bleed into the UPDATE for AG(SHIPPING).
And to what extent (or minutiae) are the procedures/functions developed. For example: while getting a name and address from a customer record is something that could be used in many programs (and SQLs) within a system (or multiple systems such as A/R and A/P accounting systems), getting just the name or phone number of the main contact for that customer record may not be necessary in but a few. Would a separate procedure be written just to grab the contact from customer record? How would that be written.
I've been very happy with my discovery of 'only write as much code as you need right now'.
I would assume that both would be in the same binding directory.
In my system, both would be in the same service program. The binding directory identifies the service programs to the calling RPG programs.
The calling RPG programs' source code does not know or identify the service program, the only thing the source code has is the sub-procedure name. Unless you are smarter than I am and name your sub-procedures
Accounting_getName() and Shipping_getName() :-)
--
--buck
Try wiki.midrange.com!
--
This is the RPG programming on the IBM i (AS/400 and 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.
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
CONFIDENTIALITY NOTICE: This electronic message transmission is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. If you have received this transmission, but are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of the contents of this information is strictly prohibited. If you have received this e-mail in error, please contact NALC Health Benefit Plan at 703-729-4677 and delete and destroy the original message and all copies.
midrange.com
