× 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: Indicator enhancements (was Bale, Dan)
  • From: Gary Guthrie <GaryGuthrie@xxxxxxxx>
  • Date: Wed, 08 Mar 2000 19:05:01 -0600

Ah, but it does have general usefulness. It's just that the silly
example I used doesn't cause the usefulness to jump out at you.

Consider that

-1 is a dead customer
-2 is a customer who never pays
-3 is an industrial spy

We never want to do business with those customers!!! :)

Consider further that the procedure is likely housed in a service
program. Some applications might need to know specific errors (hey, is
this a dead customer or a deadbeat customer!), others don't really care
about the specific error. Rather they just care that there's some error.

So, the usefulness of *NEGATIVE and *POSITIVE figurative constants is in
the ability to code a layer that is independent of the details. This
would be clearer and sometimes more performance-friendly (though this is
probably only likely if you've a large number of SELECT group WHENs)
than other alternatives. You could then use only this single layer that
indicates there is some type of error when that is appropriate, and then
when details are important you could have this first layer and if an
error of any sort is found, drill down to find the specific error.

For others who've stated a preference for just using literals in-line --
this still suffers from the points made here that you can't have
multiple conditions that "map" to a single general condition and for
maintenance reasons, it is much more preferable to have such constants
(or variables) defined in the D-specs (often optimally contained in copy
members) so that if something general changes you can change it in one
D-spec and recompile the 2000 programs that use it rather than making
changes in 2000 programs.

Gary Guthrie
REAL Technical Support
Technical Editor, NEWS/400 magazine



> > Gary sez...
> >
> > I submit it might be clearer to:
> >
> >D Error        S      N  Inz( *Negative )
> >D ExistingCust S      N  Inz( *Positive )
> >D NewCust      S      N  Inz( *Off )
> >C              Eval     RtnCode = MyProc( MyParm )
> >C              Select
> >C              When     RtnCode = ExistingCust
> > * Perform existing customer processing
> >
> >C              When     RtnCode = NewCust
> > * Perform new customer processing
> >
> >C              When     RtnCode = Error
> > ...

> Barbara sez...
>
> Gary, I don't see that *NEGATIVE appears to have general
> usefulness.  Aside from that, indicators hold boolean values.
> If you want to return more than 2 different values, use a
> type that has more than 2 values, and use named constants
> for your special values, in both your procedure and its
> callers.
> 
> D Error        C         -1
> D ExistingCust C         1
> D NewCust      C         0
> 
> C              Eval     RtnCode = MyProc( MyParm )
> C              Select
> C              When     RtnCode = ExistingCust
>  * Perform existing customer processing
> C              When     RtnCode = NewCust
>  * Perform new customer processing
> C              When     RtnCode = Error
>  ...
+---
| 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 ...

Replies:

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.