× 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: Are indicators evil creatures or victims of poor shop standards?
  • From: Buck Calabro <buck.calabro@xxxxxxxxxxxxxxxxx>
  • Date: Tue, 7 Mar 2000 09:51:25 -0500

Booth Martin wrote:

> I'm watching all of the bashing of COMP and of indicators.  These are good
> tools.  Old, understood, and true;  much like a hammer or a shovel.  The
> hammer and the shovel don't change much, a better shovel or a better
> hammer really hasn't been invented.  So sure, there's newer fads and
> fancier solutions, but indicators are not evil creatures for pete's sake.

Booth,
I would say that indicators aren't evil per se, but they do suffer from at
least two serious drawbacks:
1) They are cryptic (or terse, if you prefer)
2) They are global.

Some people find the terseness of indicators to be an asset rather than a
liability.  That's a personal preference, but by and large trsnss =
not(gdthng).  One can assign names to indicators (to alleviate the
terseness) using a construct like the one below, but traditional RPG
programmers find this... excessive.
      * Indicators are mapped to field names                 
     D@Indicators      S               *   Inz(%addr(*IN))   
     DIndicators       DS                  Based(@Indicators)
     D Exit                   03     03                      
     D AddRec                 09     09                      
     D Alarm                  30     30                      
     D SflClr                 40     40                      

The major drawback that indicators suffer from is the fact that they are
global in scope: an indicator can be changed by almost any line in an RPG
program - and also by lines in DDS too!  (Not only CF keys, but there's a
SETOFF as well...)  If terseness is not a good thing, global scope is
downright nasty.  Quick - what indicators are set here:  EXSR GETDATE?  What
fields are input or output from it?  How about this: EVAL
ARDATE=GETDATE("ARDATE")?

Global variables pretty much require strong shop standards; it is the lack
of shop standards that has resulted in messy code, and it is messy code
which has given indicators a bad name.  If you have strong shop standards,
please PLEASE post them for the common good!

Buck Calabro
Aptis; Albany, NY

+---
| 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-Ups:

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.