Re: DOW vs DOU

Kahn, David wrote:

> I think your code is perfectly clear and understandable, and as your
> technique works well for you I see no reason for you to make any changes,
> but as you asked I do have some comments to offer.

Thank you.

> First of all, you have a loop that will always be executed at least once, so
> would a DOU not be more appropriate for your technique than a DOW? 

Technically, yes, but 1 = 1 is the thing that jumps out at you and once
your brain processes that, I don't think anyone is even going to
evaluate whether it's a dou or dow, unless the code doesn't work.  

> I see the loop as an iteration of processing FMT1 and so would code it with
> a DOW with a definite ending condition signalled by the user. 

I try to stay away from using multiple condition dos, so I used to flag
a marker (F1DONE  DOWEQ *OFF or some such), but after checking
conditions, and setting the flag, I still had to bypass remaining code
with an else, leave or iter, thus the genesis of the 1 doweq 1 and leave
technique.  less mess, no need to name a variable or tag and no nested
if statements. 

> Charlie did in his example I would prime the loop, or read ahead to use
> another term, by taking out the first EXFMT. Yes, this means I will need at
> least one more EXFMT, possibly several, 
.........
> and I _should_ end up with a more robust
> program in production.

I don't have a big problem with your method, excpt for it might be a
little more messy.  I disagree with the "more robust" comment though, I
don't see anything yours can do more easily than mine.

>      DO   *HIVAL    LOPCNT 150

cool.  I kinda like that.
 
> One other thing I found a bit jarring in your code was the redundant ITER
> just before the ENDDO.

Yes, it's redundant, and the only reason for it is again for readability
- no need to go back and double check the loop to see if its a simple -
do -, dow or dou - allowing the assumption it's going to return to the
top.

> I too prefer Charlie's method of testing the function keys but I wouldn't
> make an issue of it. I would have coded your main subroutine like this.
> 
> C           F1DISP    BEGSR
>  *
> C                     EXSR F1INZ
> C                     EXFMTFMT1
>  *
> C           *INKC     DOWEQ*OFF
> C           *INKL     ANDEQ*OFF

snip, snip,

> C                     EXFMTFMT1
> C                     ENDDO
>  *
> C                     ENDSR

I'm not sure I like the priming exfmt, but I'm not sure why, since I
always code file reads that way.   food for thought....

> also have no problem at all with Charlie's use of GOTO with the ENDSR as the
> target. It's one of only situations in which I would accept the use of GOTO
> or CAB. 

Don't like gotos.  never have, never will, sorry :)

> (The other is a branch to the final statement in the detail time
> specifications when that statement is either a RETRN or MOVE *ON  *INLR.) 

Why branch?  Where does it say you can't move on lr and/or return right
there? 
To me, it's much more strait forward to just say RETRN than to branch to
somewhere else.   IMHO, of course.

> In practice, however, when coding display file edits I tend to carry on 
>through
> after finding an error to highlight as many as possible in one go,
> accumulating the error messages in a message subfile.

true, but unless they are on slow com lines, it's been my experience
that most users don't bother looking at the rest of the error messages,
they just fix the first one and press enter anyway.  As well, some
editing is dependent on the success of previous editing.  Again, just
preference.

> Thanks for sharing your ideas,

Thanks for your critique.  I've been coding cobol for a couple months,
and my brain hurts.  It's nice to at least talk about something I know
for a change.

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