× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re:Named Indicators...
  • From: "David Morris" <dmorris@xxxxxxxxxxxxx>
  • Date: Wed, 18 Aug 1999 10:11:27 -0600

Scott & Mark,

Another alternative is to use the AID byte and return the key as a 
value. This makes it a lot easier to share code and your application 
does not have to be recompiled to add, remove, or change its 
behavior. This does require some planning though. It also means 
you don't have to count on your fingers, toes, elbows, and knees 
to figure out what F24.

David Morris

>>> "Scott Klement" <infosys@klements.com> 08/17/99 11:51PM >>>
Marc,

Your solution is basing F3 on indicator 03, and F5 on indicator
05.  The original poster was looking for a way to base on KC and
KE, instead of 03 and 05.

Now -- to EVERYONE on the list:

Personally (and this is my opinion, many people have already told
me I was nuts)  I prefer to see *INKC or *INKE used instead of
*IN03/*IN05, and I also prefer to see *INKC over a "named indicator".

When I'm trying to figure out someone's code and I see this line:
C                   if        *IN03 = *On

I now have to search the source code to see what *IN03 is.   Since
its actually defined in the DDS, I won't find it.   I'll then search
the DDS, and I'll find that *IN03 is actually F3.

When I see:
C                   if        F3 = *On

I, again, now have to stop my reading of the source, search to see
what F3 is.  Find out that its based on *IN03 in the D-specs.
Now I have to search for BOTH F3 and *IN03 throughout the RPG code
to find out that its not defined.   Now I have to search all external
descriptions for F3, plus I have to search the DDS for 03.  Finally
I determine what it is.

When I see the line:
C                   if        *INKC = *On

I now know EXACTLY that this line does without having to search the
code at all.

People use "named indicators" because they don't think that *IN03
is "self-explanatory".   However, *INKC  *IS* self-explanatory, and
actually is MUCH MORE SO than a named indicator.

Sure, I can usually assume that "F3" is the same as *INKC.  But, I
know that as soon as I make that assumption, this will be the one
time that its not.

Sure, it doesn't take me more than a few seconds to determine what
a given indicator or named indicator does.   BUT, if I'm reading a
8000 line program, and I have to stop 20 different times to try to
figure out what a named indicator is, I'll get irritated.

Thats my 2 cents.

Scott Klement
Information Systems Manager
Klement's Sausage Co, Inc.



zylka.marc@westpoint-stevens.com wrote:
>
> Tim,
>
>   This is what I use and it works well.
>
> DIndicators       DS                  Based(IndicatorP)
> D  F3                        03     03
> D  F5                        05     05
> D  F12                       12     12
> D  Eof_SKU                   90     90
> DIndicatorP       S               *   Inz(%Addr(*In))
>
> Marc
>
>
> ____________________Reply Separator____________________
> Subject:    RE: Named Indicators...
> Author: <RPG400-L@midrange.com>
> Date:       8/17/99 9:36 AM
>
>   79 /*****************   Map the function Keys *****************/
>       80 d InKa            s               *   inz(%addr(*inka))
>       81 d  FunctionKey    ds                  Based(InKa)
>       82 D    F3                           N   Overlay(FunctionKey:3
>
>     Thanks, tim

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


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.