Re: Indicator Coding Technique

[RPower@xxxxxxxxxx]

KEWL!!!!!!!!!!!

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




Booth Martin <booth@xxxxxxxxxxxx> 
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
2006/01/13 02:04 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: Indicator Coding Technique






Here is an interesting solution:

http://tinyurl.com/8fjub



Booth Martin wrote:
> I suppose one could refine the technique and copy the old External 
> Switches concept, where there were 3 choices: 0, 1, or X.  X meant 
> unchanged.  So in your example:
> 
>  > if condition;
>  >   functionKeys = 'XXXX0XXXXXX0XXXXXXXXXXXX';
>  > endif;
> 
> could be used.
> 
> See how much improved a solution that is?  errr... let me count those 
> again....
> 
> Larry Ducie wrote:
>> Hi Rick,
>>
>> <snip>
>> Anyway, thank you all for your opinions. Hopefully, I will be able to 
use 
>> them to reinforce my own arguments against this "standard". At least I 
can 
>> tell them that message board was unanimously against it!
>> </snip>
>>
>> One last example to help you bury this mad idea:
>>
>> /free
>>
>> if condition;
>>   functionKeys = '000100000000001000010010';
>> endif;
>>
>> /end-free
>>
>> OK, what change didl I make to the indicators when executing the line 
above?
>>
>> Possible answers:
>>
>> 1) Switched indicator 4 on.
>> 2) Switched indicator 15 on.
>> 3) Switched indicator 20 on.
>> 4) Switched indicator 23 on.
>> 5) Switched on any combination/permutation of the four indicators 
listed 
>> above on.
>>
>>
>> Answer?
>>
>> I switched indicators 5 and 11 off. :-)
>>
>> The idea is madness. It is totally unworkable. Regarding people 
>> understanding the system once they have got used to it - it's patent 
>> nonsense. If I look at an eval statement like the one above I have no 
idea 
>> what will be changed by that statement unless I know the exact state of 
the 
>> indicators prior to the execution of the statement. The problem is, 
except 
>> for extremely simple programs, this information is only known at 
runtime. 
>> How on earth am I you supposed to develop a program with that kind of 
>> constraint?
>>
>> Sheer folly.
>>
>> ** Please deduct my account the sum of 0.02 Euro Dollars **
>>
>> Cheers
>>
>> Larry Ducie
>>
>>
>