Re: AS/400 RPG Certification Test -Reply -- MIDRANGE-L

Scott,

We initially set some goals for our use of ILE.  First we wanted to be able to 
re-use code.  Second we wanted to prevent errors.  Third, we wanted to make 
life as easy as possible for the programmer.  Each point listed addresses one 
of these goals.  We also developed utilities to automate the more mundane (and 
error prone) processes.  We have many other standards that address these areas 
but they are not ILE specific.  As Jon Paris mentioned, COMMON is a good place 
to get over the initial hurdle.

Exported procedures or values are unique across our entire system.
-Easier to find, can't bind in from the wrong module.

Procedures are used in only one program or service program.  (One exception, 
our initial sign on program)
-Only one point to change when a change is necessary.

Binding source is used for all service programs.
-Reduce recompiling necessary when changes are made.

Like procedures are grouped in a single module.
-Easier to find.

Prototypes are used on all calls.
-Very difficult to pass incorrect value to procedures.

Each module has a corresponding prototype member with the same name in 
QPROTOSRC.
-Easier to find.

Wherever a default can be established the procedure should use *OMIT and/or 
*NOPASS.
-Reduces the amount of coding required when defaults can be used.  Also tells 
the person using the procedure that a default will be assigned. 

An error flag is returned from each procedure unless the value returned can be 
used to determine whether an error occurred.
-Makes it easier to handle errors.

CONST/VALUE is used for all parameters that cannot be modified.
-More flexibility in passing parameters making use easier.

The parameters for a procedure are completely described in a heading for each 
prototype.
-One place to look to find out what defaults will be supplied, valid values, 
what the procedure does.

Everything but our menu interface program uses *CALLER.  (One exception, our 
trigger and DB modules).
-Simplifies activation group usage.  In order to share information between 
invocations we do have to assign an activation group to our database service 
program.

Service programs are grouped as universal, universal system functions, 
universal application functions, database, and application specific (Order 
entry, A/R, etc.).
This is the most questionable part.  System functions were divided to reduce 
the impact of a change.  Because of circular references this is not always the 
case.  Application specific information was divided because systems are usually 
handled by a single group or person and we didn't want to tie an order entry 
change to an A/R change.

David Morris

>>> Scott Cornell <CORNELLS@mercyhealth.com> 09/03 1:51 PM >>>
Cheerfully admitting my ignorance, I'd be interested in hearing, in
addition to what other shops have selected as standards, why you and
yours selected the procedure standards you did.  Granting it's a
pretty involved topic, just a quick thumbnail of why y'all feel what
you've decided to do works, what benefits you gain and what limitations
or drawbacks you've encountered by imposing these requirements on
yourselves (beyond the obvious reasons afforded by standards, e.g.
pgmr A can decipher what pgmr B was doing a lot quicker if they both
followed a common standard).

>>David Morris<dmorris@plumcreek.com> 09/03/98 02:15pm>>

<snip>

As far as some rules of thumb on using procedures, I would set some
standards first.  To establish those standards I would recommend
reading the ILE concepts manual, as well as the ILE RPG manuals. 
News/400 also has an RPGIV style forum that is pretty good.  The
standards that I have found most useful are:

<snip>


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---