× 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: DOU/DOW for READ Loops (My final word)
  • From: Anton Gombkötö <Gombkoetoe@xxxxxxxxxx>
  • Date: Thu, 20 Apr 2000 22:24:40 +0200

1) hundreds of lines
1) GetNextRecord
2) LEAVE, ITER, GOTO

1)
DOU
hundreds of lines
ITER
some more lines
ENDDO

this loop is much too long, not only for my taste.

2)
This GetNextRecord(FileName) is a thing that pleases my eyes at first sight.

Sudden return from paradise: How can one "handle over a file connection" (or
should i say data path? That doesn't fit for my taste, because i *can*
handover a data path with SHARE(*YES) amd that's not the case here) to an
abstract procedure? This procedure would have to read from a file that it
never heard of before and somehow fill the calling procedure's file I/O
buffer... (Giving a pointer isn't enough)

Or did you suggest to have a "local" GetNextRecord procedure (sorry,
function) with a SELECT group for every file in the module?

That would produce a nice piece of <italic>source</italic>-code, but for
what price? Is it really worth it?

I see the need for such a GetNextRecord only in cases of exclusion criterias
(due to my DOW-preference), and that's when i code a SR for it. Which i can
call ReadMyfile1, ReadMyfile2 and so on.

Or do i miss something (again:-) ?


3)
I ran already twice in the situation of a code inspection. The first time i
was warned before "GOTO, ITER, LEAVE are FORBIDDEN. You may be asked to
leave when you use on of them.". At that time i thought i use each and every
opcode that comes handy. (I never multiplied by -1, always MHLLZO -1 to
result field. What do i care whether the next one reading the code isn't
smart enough to know what it does?) I felt like a kid who had to give some
of his toys away. I learned that code is prettier, philosophically cleaner,
without the mentioned unstructured opcodes.
The second time i was in a similar situation, but on the other side, the
side of the non-users of GOTO, LEAVE and so on.

So the common DOU-loops with the LEAVE's or ITER's don't suit me. I think
it's ridiculous to fight for the beauty of code and use these opcodes (in
loops spanning 23+ lines). (Lend me that asbestos, Dan, quick!!!)

0.06 Euro (3 times 0.02)

Anton Gombkötö

----- Original Message -----
From: "Chris Bipes" <rpg@cross-check.com>
To: <RPG400-L@midrange.com>
Sent: Thursday, April 20, 2000 7:09 PM
Subject: RE: DOU/DOW for READ Loops (My final word)


> <snip>
> Anyway, the important thing is to fully understand both methods because we
> all will inevitably see both.  Now that I've added myself to this silly
> debate, I'll sign off and watch the flames fly!  <g>
> <snip>
>
> I could not agree with you more.  We have several applications that have
> complex record selections joining data from multiple files.  90% thru the
> code, (hundreds of lines and several file reads later), we reject the
record
> and do not post or print it.  This is where ITER comes in handy.  Oops I
> just skipped the read of the next record coded at the end of the DOW...Dam
> it anyhow.
>
> I have been known to use the DOU when the code within the loop is simple
and
> straight forward.  I use what works best for the application at hand.
>
> Now the procedure that reads the record in the loop control example has
> great promise.
>
> DOW   GetNextRecord(FileName)
> (Notice No More Leave!)
> >
> .
> .
> If condition = *fails
> Iter
> EndIf
> .
> .
> .
> ENDDO
>
>
> I am going to give it a try when I get a Chance.
>
>
> Christopher K. Bipes mailto:ChrisB@Cross-Check.com
> Sr. Programmer/Analyst mailto:Chris_Bipes@Yahoo.com
> CrossCheck, Inc. http://www.cross-check.com
> 6119 State Farm Drive Phone: 707 586-0551 x 1102
> Rohnert Park CA  94928 Fax: 707 586-1884
>
> If consistency is the hobgoblin of little minds, only geniuses work here.
> Karen Herbelin - Readers Digest 3/2000
> +---
> | 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
> +---

+---
| 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.