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



Sorry to say this, but the coding techniques needs a lot of
reconsideration. I would have the think for a long time to make the loop
any more complex when it doesn't have to be.

This looks like a traditional "position the file and enter a loop,
process the rest of the file" routine. All those other IFEQ in that loop
are out of place.

Basically, in this kind of routine you do this:

  Position the file (your CHAIN operations
  Enter the DOxx loop. Usually on a Record Found condition, so something
like:
   *IN96  DOWEQ *OFF
   *IN97  ANDEQ *OFF

But that depends on whether you want the routine to end when EITHER
files hits the end-of-equal-key (EOF) condition.

The next thing is usually to put your processing (code) in the start/top
of the DOxx loop. Then at the bottom, do your READE operations with the
96 & 97 indicators.  No more testing is needed because the DOWEQ
condition test the status once each iteration. The only really logical
difference between a DOWxx and a DOUxx is that the conditional test for
DOWxx is performed at the top of the loop, and DOUxx is performed at the
logical bottom of the loop. Hence DOUxx loops are _always_ run at least
one time.


Bob Cozzi
cozzi@rpgiv.com
Visit the new on-line iSeries Forums at: http://www.rpgiv.com/forum

> -----Original Message-----
> From: rpg400-l-admin@midrange.com [mailto:rpg400-l-admin@midrange.com]
On
> Behalf Of darren@dekko.com
> Sent: Tuesday, November 13, 2001 12:59 PM
> To: rpg400-l@midrange.com
> Subject: RE: DOUEQ - Loop (RPG III)
>
>
> hrishikesh,
>
> Jim L. is correct.  Either change the test to *ON or use DOWEQ.  There
are
> some other logic errors in this program.  Here's a hint, make sure
*IN97 is
> set everywhere it should be, and is Overflow going to work the way its
> intended?
>
>
>
>
>
>                     rpg400-l-request@mi
>                     drange.com                To:
rpg400-l@midrange.com
>                     Sent by:                  cc:
>                     rpg400-l-admin@midr       Fax to:
>                     ange.com                  Subject:     RPG400-L
digest,
> Vol 1 #199 - 3 msgs
>
>
>                     11/13/2001 01:01 PM
>                     Please respond to
>                     rpg400-l
>
>
>
>
>
>
>
>
> From: Jim Langston <jlangston@celsinc.com>
> To: "'rpg400-l@midrange.com'" <rpg400-l@midrange.com>
> Subject: RE: DOUEQ - Loop (RPG III)
> Date: Tue, 13 Nov 2001 09:43:34 -0800
> Reply-To: rpg400-l@midrange.com
>
> <QUOTE>
> "I checked this in Debug and found that even if
>  *IN97 & *IN96 are *OFF the loop ends?!!!"
> </QUOTE>
>
> Umm.. that's what you're telling it to do.
>
> 30600 C     *IN97  DOUEQ*OFF
> 30700 C     *IN96  ANDEQ*OFF
>
> Do until both *IN97 and *IN96 are off.
>
> -----Original Message-----
> From: hrishikesh kotwal [mailto:hdkotwal@hotmail.com]
> Sent: Tuesday, November 13, 2001 9:34 AM
> To: rpg400-l@midrange.com
> Subject: DOUEQ - Loop (RPG III)
>
>
> [ Converted text/html to text/plain ]
>
> Dear all,
>
>
>
> With reference to one of my earlier mails regarding Line Count, I had
> received
> a solution to match records and print them. In that solution DOUEQ
loop was
> used. I have used this in my program and it has successfully printed
most
> of
> the records. But today I noticed a bug in my loop. Following is the
loop:
>
> 21800 **------------------------------------------------------------
>
> 28600 C    DTL020 BEGSR
>
> 29300 C            SETOF                   97
>
> 29400 C    DDCINB  CHAINCMBF4CL1           97
>
> 29500 C            SETOF                   96
>
> 29600 C    DDCINB  CHAINCMBF4D             96
>
> 30600 C     *IN97  DOUEQ*OFF
>
> 30700 C     *IN96  ANDEQ*OFF
>
> 30900 C     *IN97  IFEQ *ON
>
> 31000 C     *IN96  ANDEQ*ON
>
> 31100 C            LEAVE
>
> 31200 C            ENDIF
>
> 36800 C            EXCPTPRTDT4
>
> 37000 C  OA        EXCPTPRTHDG
>
> 37200 C  OA        SETON              OA
>
> 37800 C     *IN97  IFEQ *OFF
>
> 37900 C     DDCINB  READECMBF4CL1
>
> 38000 C             ENDIF
>
> 38200 C      *IN96  IFEQ *OFF
>
> 38300 C      DDCINB READECMBF4D               96
>
> 38800 C            ENDIF
>
> 39000 C      *IN97 IFEQ *ON
>
> 39100 C      *IN96 ANDEQ*ON
>
> 39300 C            EXCPTPRTDT5
>
> 39500 C            ENDIF
>
> 39700 C            ENDDO
>
> 39800 C*
>
> 39900 C            ENDSR
>
> ------------------------------------------------------------------
>
> I read files CMBF2CL1 & CMBF2D together for a common DDCINB (Item
Number).
> Both files may have none or multiple records for DDCINB. I want to
print
> whatever records exist in both files for DDCINB. Therefore I am trying
to
> use
> the Match Record Processing logic BUT My problem is that when CMBF2CL1
&
> CMBF2D have more than one record for the same DDCINB the loop fails. I
> checked
> this in Debug and found that even if *IN97 & *IN96 are *OFF the loop
> ends?!!!
> How is this possible? Is there something wrong in this loop.
>
>
>
> Please help.
>
>
>
> Regards,
>
> Hrishikesh Kotwal
>
>
>
>
> _______________________________________________
> This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing
list
> To post a message email: RPG400-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
> or email: RPG400-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/rpg400-l.




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.