Indicators Was (RE: Hi New to list. QCMDEXC Question Kind of long. Thanks a lot.)

Yes I stopped using numbered indicators a while ago, but for display file 
and printer files still can't get away from them.  I like to use one 
indicator for reverse image and position to, then if an error is found, 
flip on the indicator, and based on which error condition was found, 
populate the error message and send it to the user using QMHSNDPM API. 
Thereby I can use one indicator for say 5 different error scenarios on the 
one field.

Ron Power
Programmer
Information Services
City Of St. John's, NL
P.O. Box 908
St. John's, NL
A1C 5M2
Tel: 709-576-8132
Email: rpower@xxxxxxxxxx
Website: http://www.stjohns.ca/
___________________________________________________________________________
Success is going from failure to failure without a loss of enthusiasm. - 
Sir Winston Churchill




"Dan Bale" <dbale@xxxxxxxxxxxxx> 
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
16/08/2004 12:15 PM
Please respond to
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>


To
"RPG programming on the AS400 / iSeries" <rpg400-l@xxxxxxxxxxxx>
cc

Subject
RE: Hi New to list. QCMDEXC Question Kind of long. Thanks a lot.






> -----Original Message-----
> From: rpg400-l-bounces@xxxxxxxxxxxx / RPower@xxxxxxxxxx
> Sent: Monday, August 16, 2004 9:57 AM
>
> Hehe yeah I'm 29 yrs old now.  Started this when I was 23.  I try to 
make
> sure that complex code is documented.  Around here, if you don't, 
they'll
> chop off your fingers which is a nice touch.  I'll usually document 
about
> 30% as much as I code.  If the documentation ends up looking like
> *Chain to file to get record -> I usually leave stuff like that out
> because you can see it in the code.  But if it's more complex like a
> calculation of rates based on steps, I'll usually try to get the point
> across in plain English with a written example as to how the input and
> output should like, just in case someone reads it in the future and 
tries
> to figure out just what I'm doing.  <snip>

Generally speaking, and IMO, I don't like to see documentation 
interrupting
the flow of code.  If some code needs to be documented, the code should be
in a subroutine / subprocedure / service program, and that needs to be
documented.

> I also make
> sure that I list each and every indicator used in the program so that 
you
> don't have to guess if it's used or not.  Whether or not my colleagues
> keep that up to date is another story lol.  I've heard the phrase "just
> compile it and it'll tell you the indicators used" but to me that's a
> couple minutes I could have saved so I could read my RPG List email :)

Indicators?  You use indicators?

Well, yes, of course, just not numbered indicators, right?  Unless they're
display or printer file related?  I like to use named indicators when they
can be used in conjunction with If, When, Dox, and it can be read in
English-like terms.

 d Customer#IsValid...
 d                 s               n
 c     Key           Chain     CusMas
 c                   Eval      Customer#IsValid = %found(CusMas)
..........
 c                   If        Customer#IsValid

Sure beats the heck out of "If  *in25" and it's self-documenting.  Some 
may
prefer just using the %found(CusMas) as the "indicator".

db

--
This is the RPG programming on the AS400 / 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.




This OutBound email has been scanned for Viruses