We reduced it to a minimum of rules:
1. everything that can be reused, is an external procedure/function in an
service program
2. Procedures/functions can be understood as "mini" programs and should be
little black boxes, i.e. everything between the procedure and the caller is
exchanged via parameter. The use of global variables should be reduced to a
minimum.
3. procedures/functions are grouped according to their functionality into
modules, e.g. all date functions, all string functions, all
insert/update/delete routines for a specific table etc.
4. I prefer to create a service program for each of these modules and list
the service program in a binding directory, that is specified when binding
the service program.
5. All service programs that include procedures that can be universally used
(i.e. date functions, string functions) are created with a named activation
group (for example Service Program Name = Activation Group Name). In this
way these service programs are only activated once within the job and stay
active until the activation group is explicitly reclaimed.
6. all service programs including Insert/Update/Delete Routines are created
with activation group *CALLER (due to the use of commitment control which is
started per default with Commimtent Scope *ACTGRP).
7. Programs consist mainly of external procedure/function calls with a few
ifs/dos etc.
8. Internal procedures are used very rarely and include only steps that are
really unique for the (service-)program, for example initializing global
variables.
Mit freundlichen Grüßen / Best regards
Birgitta Hauser
"Shoot for the moon, even if you miss, you'll land among the stars." (Les
Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them
and keeping them!"
?Train people well enough so they can leave, treat them well enough so they
don't want to.? (Richard Branson)
-----Original Message-----
From: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Brian May
Sent: Donnerstag, 2. Februar 2017 16:56
To: RPG programming on the IBM i (AS/400 and iSeries)
<rpg400-l@xxxxxxxxxxxx>
Subject: RE: Procedure Examples VR7.1
Generally speaking. Whether batch or interactive, when a procedure is
called, the service program will be loaded into the activation group and
remain there until the job ends or the activation group is reclaimed. There
would be no extra overhead on subsequent calls to the procedure.
Brian May
Director
Pre-Sales and Customer Solutions
Profound Logic Software
http://www.profoundlogic.com
937-439-7925 Phone
877-224-7768 Toll Free
The IBM i Modernization Experts
www.profoundlogic.com
2017 State of IBM i Modernization Survey Take the survey and enter to win
prizes Survey ends February 3, 2017 - Enter now!
-----Original Message-----
From: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Duane
Scott
Sent: Thursday, February 2, 2017 9:49 AM
To: RPG programming on the IBM i (AS/400 and iSeries)
<rpg400-l@xxxxxxxxxxxx>
Subject: RE: Procedure Examples VR7.1
Ok. Some clearer. But I sometimes need to sleep on things awhile when
there is nobody to hit me over the head with clear examples.
Situation: I have a single $ figure that would be obtained from one of three
files depending on several factors, say 3 or 4. I could use a procedure to
obtain the $ figure in a display program for the user benefit and in a batch
process that MAY need the $ figure on each of many records but not all.
I can see a bind by reference being the best for the display program, but
would it also be best on the nightly process? Once invoked, would the
referenced procedure become part of the job or each instance of need be
"loaded" into the job and cause additional overhead during the run? (Does
this even make sense, or am I not seeing the picture at all?)
duane
-----Original Message-----
From: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Bradley
Stone
Sent: Thursday, February 02, 2017 10:15 AM
To: RPG programming on the IBM i (AS/400 and iSeries)
<rpg400-l@xxxxxxxxxxxx>
Subject: Re: Procedure Examples VR7.1
Duane,
Service Programs vs Modules is one of those things that is very dependent, I
feel, upon where and how it's used.
If I'm writing code for a shop for our custom software, I'll most likely use
service programs (bind by reference) for most of the functions.
If I'm writing code to be distributed (as I do as an ISV) for most of the
internal functions I use modules (bind by copy).
For functions I want to make available to customers I use service programs.
Even YAJL I'm now using as bind by copy. Scott and I ran into an issue with
my software vs Help systems using different versions of the service program.
I had anticipated this earlier and made the latest versions of my software
that use YAJL bind by copy. The customer installed the new version of my
software and things were honky dory again.
Never say never. Never say always.
Bradley V. Stone
www.bvstools.com
Native IBM i e-Mail solutions for Microsoft Office 365, Gmail, or any Cloud
Provider!
On Thu, Feb 2, 2017 at 8:25 AM, Duane Scott <dscott@xxxxxxxxxxx> wrote:
Whoa. Wait! Not understanding this concept.
I bow to the experts on this as I'm most assuredly not proficient, but
I need clarification and pictures and diagrams (yes, I'm that old).
I'm fairly understanding of how procedures work, but I've not been
able to sit down with someone who uses it in a working environment.
Can you elaborate on the "Bad, bad thing to do." (More specifically)
what is it that is bad and why?
Duane
-----Original Message-----
From: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of
Alan Campin
Sent: Wednesday, February 01, 2017 4:53 PM
To: RPG programming on the IBM i (AS/400 and iSeries) <
rpg400-l@xxxxxxxxxxxx>
Subject: Re: Procedure Examples VR7.1
As you note, I use the Service program name. Obviously easy if you
know the service program name to find the module it is in and usually
a service program only has one member anyway and please never bind the
same module to multiple programs or service programs. Bad, bad thing
to do. Create service programs.
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.
--
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
--
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
midrange.com
