× 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: DOW vs DOU
  • From: cmassoglia@xxxxxxxxxxx (Charlie Massoglia)
  • Date: Thu, 29 May 1997 23:44:58 -0400

Rick:

The 1 DOWEQ 1 construct is not really the logic of the loop.  The logic of
the loop is really continue the loop until you press F3 or F12 to exit.
Instead of using *INKC and *INKL we normally define an INFDS and check the
AID byte.  (Remember S/3 CCP and RPG II?)  The named constants could be
copied using a /COPY.  We would also use SELEC/WHEN instead of a series of
IF/ENDIFs.  We would probably code the same routine as follows: 

FSCREEN   CF    E               WORKSTN    KINKDS   SCRNDS

IDsname....NODsExt-file++............PFromTo++DField.........
ISCRNDS     DS
 * ATTENTION INDICATOR
I                                      369 369 $$FKEY

I..............Constant++++++++++++++C.........Const+........
 * NAMED CONSTANTS
I              X'31'                 C         ##F01
I              X'34'                 C         ##F04
I              X'3C'                 C         ##F12

C       F1DISP     BEGSR

C                  EXSR  F1INZ             (any pre-screen processing)

C                  MOVE  'N'      #EXIT1
C       #EXIT1     DOWNE 'Y'                (loop continues until ,
C                  EXFMT FMT1                exit set)

(#EXIT1 DOWEQ 'N' would also be valid but I tend to think in the negative.)

C                  SELEC

C       $$FKEY     WHEQ  ##F03               (If F3 or F12 is
C       $$FKEY     OREQ  ##F12               pressed, set loop exit)
C                  MOVE 'Y'       #EXIT1                    

C       $$FKEY     WHEQ  ##F04
C                  EXSR  @@INQ1            (prompt/lookup inquiry calls)

C                  OTHER
C                  EXSR  @@EDT1            (input field editing)

C       $ERROR     IFNE  'Y'
C                  EXSR  @@UPD1            (file update)
C                  EXSR  @@INZ1
C                  ENDIF

(Again, $ERROR IFEQ 'N' could also be used.)

C                  ENDSL

C                  ENDDO

C                  ENDSR

For the edit routine, instead of coding a DO at the start of the subroutine
and an ENDDO several pages later, we always reverse the subroutine name to
form the ENDSR tag.  An @@xxxx ALWAYS represents a subroutine BEGSR and a
xxxx@@ ALWAYS represents the end of the subroutine. Yes, the GOTO drives
structured purists wild but an exit to the end of a routine is structured
code and we ALWAYS code this the same way in every program.  This is the
only time we use a GOTO and will do so until we get a LEAVE type op code to
exit a subroutine.

C       @@EDT1     BEGSR

C                  MOVE  'N'       $ERROR

C       KEY1       CHAIN FILE1              90
C       *IN90      IFEQ  *ON
C..... insert your error messaging code of choice
C                  MOVE  'Y'       $ERROR
C                  GOTO  EDT1@@
C                  END

C       KEY2       CHAIN FILE2              90
C       *IN90      IFEQ  *ON
C..... insert your error messaging code of choice
C                  MOVE  'Y'       $ERROR
C                  GOTO  EDIT@@
C                  END

etc....

C       EDIT@@     ENDSR

If I am on the second edit, I can F EDIT@@ 18 or F ENDSR to easily go to the
end of the subroutine in SEU.

We do use ITER and LEAVE in DO, DOW, and DOU loops where appropriate.

I anxiously await (look forward to?) the condemnations for using a GOTO.  Be
nice - remember no flames!

Rick wrote:

>Since were on the subject, I would like some opinions on a coding
>technique that I've been using for several years now.  I use the LEAVE 
>and ITER opcodes extensively as a sortof GOTO replacement (ooh, maybe
>that isn't such a good thing to compare it to.....
>
>I like it (obviously) and I think it makes things a lot kinder on the
>eyes.
>
>Here are a couple of examples: (doesn't line up, spaces added between
>opcode and factor 2 to make it more readable)
>
>for screen processing subroutines:
>
>C       F1DISP     BEGSR
>
>C                  EXSR  F1INZ             (any pre-screen processing)
>
>C       1          DOWEQ 1                 (obvious never-ending loop,
>C                  EXFMT FMT1               requires LEAVE to exit)
>
>C       *INKC      IFEQ  *ON               (leave loop if F3 or F12 is
>C       *INKL      OREQ  *ON                pressed)
>C                  LEAVE                    
>C                  END
>
>C       *INKD      IFEQ  *ON
>C                  EXSR  F1PRMT            (prompt/lookup inquiry calls)
>C                  ITER                    (return to screen)
>C                  END
>
>C                  EXSR  F1EDIT            (input field editing)
>C       $ERROR     IFEQ  *ON
>C                  ITER
>C                  END
>
>C                  EXSR  F1UPDT            (file update)
>C                  EXSR  F1INZ
>C                  ITER
>C                  ENDDO
>
>C                  ENDSR
>
>and the edit routine:
>
>C       F1EDIT     BEGSR
>
>C                  MOVE  *OFF      $ERROR
>
>C                  DO
>
>C       KEY1       CHAIN FILE1              90
>C       *IN90      IFEQ  *ON
>C..... insert your error messaging code of choice
>C                  MOVE  *ON       $ERROR
>C                  LEAVE
>C                  END
>
>C       KEY2       CHAIN FILE2              90
>C       *IN90      IFEQ  *ON
>C..... insert your error messaging code of choice
>C                  MOVE  *ON       $ERROR
>C                  LEAVE
>C                  END
>
>etc....
>
>C                  ENDDO
>
>C                  ENDSR
>
>These techniques cut down on the nesting levels, and the code is very
>re-usable.
>
>Comments?  Does anyone else use the leave and iter opcodes as much?
>
>Is this readable to someone not used to seeing things done this way?
>
>Thanks, 
>
>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   *
>* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>uucp
>
>


Charlie Massoglia, Massoglia Technical Consulting, Inc.
PO Box 1065, Okemos, MI 48854, USA
517-676-9700  Fax: 517-676-1006  EMAIL: cmassoglia@voyager.net


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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.