Re: DOW vs DOU

[rbbaird@xxxxxxxxxxx (Rick Baird)]

John Carr wrote:


> Others (With different standards)  may say "How much simpler can you get
> than saying (IN03 IFEQ *ON)  or maybe (*IN12 IFEQ *ON)?  These people
> may work in shops where *IN01 -> *IN24 are ALWAYS F-keys response
> indicators.  Would they be wrong? (on the other hand I have never
> personally met a person who could tell me what function key
> *INKQ  or *INKJ was without looking at the sky or his/her shoes
> (But if I said "*IN03 = F3,  guess what Fkey *IN18 is",  100% get it right)

I would prefer the aid byte but don't use it very often, mainly because
I'm working based on the clients standards.  INK* is my second choice. 
Never use 01-24 and change them wherever I see them.  You never know
when someone is going to re-use one of them.

> I personally look at the following section of code(at bottom
> of this post) and say "You can make it simpler and more generic/clonable"

I cant tell if the first snippet was yours, or a copy of someone elses,
but I do recognize the last one as mine.
I dare say that both are equally easy to understand, and equally
clonable.

> Separate the Logic control from the Data manipulation code.

Absolutely.  my code has no data manipulation in the screen handleing
routine.

> If its a screen processing routine;
> 1. Then Present the screen,
> 2. Determine which function/enter key was pressed. and
> 3. Process the routine that handles THAT function/enter key.
> My mainline screen processing routine is generally about 20-30 statements
> It does not usually have any data manipulation at all, just control logic

yewbetcha!  mine too.

> I have a S1ENTER key subr. for "Screen 1 Enter key" processing.
> It generally contains only CASxx or SELECT/WHEN functions.

usually my "OTHER" or whatever is left after my iter/leaves, but without
using the aid byte, I have to rely on the "leftovers".

> I have a subroutine for each function key.  Only things that pertain
> to that function key are in there. Generally these do NOT have any
> CAS,SELECT, or IFxx statements.  They just do the Fkey function thats
> it.

ditto.

> And also I do not set flags or indicators to "Bubble" me up and out of
> numerous low level subroutines/DO loops.

Never use 'em myself.  I don't even like control variables for my loops
(#exit1, etc) which is why I use the "1 doweq 1" leave/iter/continue
technique.

> For example I personally have 
> no problem with saying (*IN03 CASEQ *ON     EXIT).  in the mainline or
> even some low level functional subroutine.  I have a subroutine called
> EXIT which uses the RETURN function.  

I totally agree. - though I didn't use that method in my example - I
didn't want to cloud the issue at the time.

> It may or may not set on *INLR
> in the particular program  but THE ONLY WAY OUT of the program is
> that door.  I find numerous RETURNS through out the program "Not Neat"

If all I'm doing is flipping LR and returning (or just returning) then I
have no problem with doing it multiple times.  If there is anything else
to do at lr processing, then I'd move it all to a subroutine.  maybe not
very consistant, but...

> The last line in my Mainline section is a Failsafe EXSR   EXIT.

again, me too (or a return).

About my code, you say that "You can make it simpler and more
generic/clonable" All of the examples you sited, are employed in the
code snippet I gave (and you quoted at the bottom of your post), done
just a little differently than the way you described.  So, I'm not sure
whos code you could make simpler.

> Just my $.02 but I maybe wrong.

it's worth a little more than that :)

regards,

rick
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* 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   *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *