RE: Additional RPGLE Enhancement Requests -- MIDRANGE-L


With this example, what's wrong with a little fall-through logic and a   
subroutine?

C'mon Charlie!  Where's the left-hand indicators?  ;)

This is all a style issue, but for this example, I'd:

1.  Split the hold logic away from the basic validations.  All you want   
to know at this point is if the customer is on hold.  So, a little   
subroutine (or an external function) might be useful here.  Particularly   
for maintenance.  You may change the rules on what puts a customer on   
hold, and imbedding that kind of logic in a validation routine can make   
things thorny.  Particularly for maintenance.

2.  Use fall-through logic to handle the editing:

C EDIT  BEGSR
C*
C ITEM  CHAINITEMMAST  20...
C*
C *IN20  IFEQ *OFF
C CUST  CHAINCUSTMAST  21
C*
C *IN21  IFEQ *OFF
C   EXSRHLDCHK
C ONHOLD IFEQ *OFF
C *IN22  OREQ*OFF   ;What does an *IN22 do?  I dunno.
C*
C* <BLAH, BLAH, WOOF WOOF -- REST OF ROUTINE>
C   ENDIF
C   ENDIF
C   ENDIF
C*
C   ENDSR

3.  And althought it's off-topic, avoid variable names and tag names with   
special characters (@, #, %, etc).  It annoys the international community   
when the code pages in source files don't translate properly, so no   
@@EDIT and EDIT@@ tag names.

Yeah, I know this invites tons of IF-ENDIF blocks.  But that's when it's   
time to look at the validation and see how it can be further broken down   
into seperate subroutines.  It's more complex but I find it's more   
readable.

OK, I'm done...let the flames begin...
 ----------
From:   
 midrange-l-owner%midrange.com[SMTP:midrange-l-owner%midrange.com@mcs.com]  

Sent:  14 July 1997 09:30
To:  MIDRANGE-L
Subject:  Re: Additional RPGLE Enhancement Requests

Dean:

Please tell me how I properly structure a screen edit routine where the   
user
has requested serial editing, i.e. stop and redisplay the screen as soon   
as
the first error is encountered.  I would code it as follows:

C          @@edit      betsr
 *
C          item        chain  itemmast         20....
c                      if     *in20
c                      goto   edit@@
c                      endif
 *
c          cust        chain  custmast         21....
c                      if     *in21
c                      goto   edit@@
c                      endif
 *
c          cmhold      ifeq   'Y'
c                      eval   *in22 = *on
c                      goto   edit@@
c                      endif
 ...
c          edit@@      endsr

How would you code this without using a GOTO, without testing an error   
flag
repeatedly, and without using a DO *FOREVER/LEAVE construct?

>>  >>13.  We have ITER and LEAVE to exit a do loop.  How do we exit a
>>  >>     subroutine without doing a GOTO.  What above an operation code
>>  >>     to GOTO *ENDSR just like ITER does a GOTO ENDO and LEAVE does
>>  >>     a GOTO ENDO+1.  I have no idea what to call the op code.  I
>>  >>     just know we desparately need it.  (This should be trivial -
>>  >>     please fix it.)
>>  >
>>  > How about LEAVESR ?
>>
>>
>>  Why not just put a TAG on the ENDSR and GOTO it?  Does the same   
thing,
>and,
>>  if you call it something like LEAVE/EXIT/QUIT it's fairly obvious   
what
>it's
>>  doing.
>>
>>  All this just to avoid the use of a GOTO....  *sigh*
>
>RRRRRRrrrrrrrrrrr!  How about just structuring your logic so that it   
FALLS to
>the ENDSR?  Why should subroutines be any different from mainline logic?   
 A
>LEAVESR command would be USELESS if the code were structured properly in   
the
>first place.  I've found places for using both ITER and LEAVE,   
especially
>when converting S/36 code.  I HAVE YET to find a place in my heart for a   
GOTO
>:-).
>


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


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