In your opinion, are your rules generally consistent with the needs of an
organization maintaining its own home grown software? If not, in what way
would you modify them?
These rules can be transported to any application. We have several customers
who modernized their applications with the same rules.
What you need: Good naming conventions (so you colleague is able to find the
procedure he needs and does not reinvent the wheel because he did not find
it)
You can go step by step. First find out subroutines or copy members that are
used more than once, then write the procedure/function, test it and replace
the subroutine or copy member with this function/procedure.
At first your procedures may be too big. But as soon as you get experienced
you'll split your big procedures into smaller ones and your big procedure
only calls the smaller procedures.
BTW without ILE concepts we would not have been able to write our WOPiXX
product, that allows RPG programmers to write Web applications without
knowing anything about JavaScript, Stateless Programming, HTML, PHP etc.
Since WOPiXX is free, I poste the web site here:
http://www.wopixx.com/en
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 Duane
Scott
Sent: Freitag, 3. Februar 2017 16:52
To: RPG programming on the IBM i (AS/400 and iSeries)
<rpg400-l@xxxxxxxxxxxx>
Subject: RE: Procedure Examples VR7.1
Great list of rules, Birgitta. Many thanks.
I wish I spoke German, so I could read more about your organization and its
software. (for curiosity more than to fill a need at my organization.)
Gathering from what I can read (in the "German to English translator" on
Google), your organization supplies software for other companies. In my
mind that would be an ideal situation for using procedure based software.
Using a set of rules is ideal and just what I consider a necessity.
In your opinion, are your rules generally consistent with the needs of an
organization maintaining its own home grown software? If not, in what way
would you modify them?
duane
BTW, I like your "signature statements". Just wish most organizations felt
the same. I'm not sure they do. Actually, I'm pretty sure they don't.
Maybe it's just the ones that would pick me as their candidate for
employment. Maybe I should look to myself.
-----Original Message-----
From: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Birgitta
Hauser
Sent: Friday, February 03, 2017 1:21 AM
To: 'RPG programming on the IBM i (AS/400 and iSeries)'
<rpg400-l@xxxxxxxxxxxx>
Subject: RE: Procedure Examples VR7.1
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)
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
midrange.com
