× 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 (was DOW vs DOU)
  • From: John Carr <74711.77@xxxxxxxxxxxxxx>
  • Date: 27 May 97 22:47:14 EDT

Message text written by INTERNET:MIDRANGE-L@midrange.com
>>David Gibbs wrote:
>> There's no reason you can't move *ON to any 1 character field... 
>> D rnfINP30      S                       LIKE(*IN90)
>> C                            CHAIN    INR30                     90
>> C                            EVAL       rnfINP30 = *IN90
>> C                           IF  rnfINP30 = *ON
>> C               ENDIF
>> 
>> Get my meaning?
>> 

>Yes, that does work.  In our shop we use a single indicator for ALL
>chain and read operations and move the result to a unique variable by
>record retrieved. (ie: CUSThit, ITEMhit)
>Just a personal preferance to use a variable that responds with yes/no
>instead of on/off.
>I suppose it's how you name the variable-- <
>James W. Kilgore 

James;

I'd  be willing to bet that even "CUSThit,  ITEMhit"  doesn't always mean the
same thing in all programs.  What if you're using three ODP's to the same
file(PF, & a couple of LF's over the same PF).?  Do you resort to " CUSThit, or
CUSThit01, CUSThitLF1,   etc, etc"   

Does EVERY programmer use the same label (CUSThit) for the same file?  Or are
they a "Variations on a Theme"  kind of thing?  The reason I'm asking is I've
seen that sometimes even named variables do not automatically produce clear
understanding( See the ramblings in one of my recent posts about Russian General
names as variables).  

I agree that indicators are not "self evident"  in their meanings,  But on the
other hand,  I have been in shops that had STRICT standards concerning
indicators  and in EVERY program indicators 1-29 were function keys (F1-F24,
Home, etc.)  and so on.  And in those cases I'd rather have consistent obtuse
indicators than have named variables that change their meanings from routine to
routine or program to program, or be named after russian generals or parts of
boats (EXSR ANCHOR?). 

I also use a variable called ERRORS  that I use as in the following; (BTW No &
YES are named constants we standardly use(is that a word?))

EVAL      ERRORS    =  NO
EXSR     EDIT
IF             ERRORS  =   NO
EXSR     UPDATE 
ENDIF
This is consistent,  self-evident,  you know what it means and you haven't even
seen the program.

Can the code be cloned?  Will it mean the same thing from routine to routine, or
program to program?  If you look at a routine, without seeing the rest of the
program will you understand it?

Just some thoughts

John P. Carr  
EdgeTech
 
P.S. BTW  James I wrote the previous post about scanning for *IN9x and in that
same post I said that if I did something that would obscure the scan results (ie
MOVEA) that the same lines's comment area(at end of calc spec) would contain the
scan target(ie Reset *IN90 - *IN99).  I do agree the compiled listing is the
only way to know for sure,  BUT IT HIGHLY DEPENDS ON HOW WELL YOUR SHOP ENFORCES
IT'S STANDARDS.    And   MOVE   *OFF   *IN90  is better (IMO) than SETOF   90
for  a number of reasons. And   MOVEA is expensive only in a VERY relative way (
whats two times zero?)
:-)  just opinions,   but I'm probably wrong.

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This is the Midrange System Mailing List!  To submit a new message,   *
* send your mail to "MIDRANGE-L@midrange.com".  To unsubscribe from     *
* this list send email to MAJORDOMO@midrange.com and specify            *
* 'unsubscribe MIDRANGE-L' in the body of your message.  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.