DOW vs. DOU - Long Live the...

[Susan Durrie <sed1@xxxxxxxxxxxxx>]

On May 27, 1997, Dave Kahn replied as follows:
_______________________________________________________________________
>And just to stir up trouble, I'll throw in the following that I
>use in certain circumstances:
>
>   KEY       CHAINFILEXXX              90
>
>  *IN90     DOWEQ*OFF
>  XXCODE    ANDNE'B'
>
>  XXCODE    CABEQ'A'     NXTRCD
>
> <.... whatever process ....>
>
>  NXTRCD    TAG
>  KEY       READEFILEXXX                  90
>            ENDDO

No, no, no, no, no, no, no. I can't bear it. IFNE 'A'/ENDIF would be 
preferable to CABEQ'A'/TAG. It is never necessary to code a GOTO or it's 
upwardly mobile cousin CAB in an RPG program. Of course, your code does
one 
saving grace that mine lacks. It works. :-)
________________________________________________________________________
Okay, Okay.  Just for the record.  Many years ago, I came out of
a programming school which was so strict on structured programming
and walkthrough methodology that if you used a GOTO (strictly
tabu) or could not compile in 2 tries, you failed.  (You know, just
like in real life. :-) )

I've seen my share of spaghetti code -- usually old COBOL. They used
to throw me and I'd spend a lot of time rewriting.  A GOTO or CAB (RPG)
would cause me to open my mouth in a big gaping Oh my gosh! Then I
became
a consultant.  Get in, fix it, get out.  I'm flexible; adaptable; no
longer
a purist.  Although I still consider myself a STRONG advocate
of structured programming and write my own stuff in what I consider
structured code, I value common sense (i.e., read ease of maintenance)
over ironclad rules.

Above all, I write it exactly the way they want it in their shop.  There
is nothing faster for maintenance than to have all programs written the
same way.  

Anyway, to get back to the point, the following technique is something
that
I have become comfortable with in long validation subroutines where you 
want to get out after the first error and a SELEC statement is not
appropriate.
Of course, you could preface each issue with an @ERROR   IFNE  'Y', but
why
waste time checking each IF statement?
_______________________________________________________________________________
Okay, here goes.  I guess I'm up to $.04 now.
  *LOVAL    SETLLFILEXXX
            READ FILEXXX              90
  *IN90     DOWEQ*OFF
            EXSR VALID  
< .... I would put ALL exceptions and validation in the subroutine ....>
  @ERROR    IFNE 'Y'
            EXSR PROCES
            ENDIF
            READ FILEXXX                  90
            ENDDO
            MOVE *ON    *INLR
**********************************************
  VALID     BEGSR
            MOVE 'N'    @ERROR    1
* Can't have this or this
  XXCODE    IFNE 'A'
  XXCODE    ORNE 'B'
            MOVE 'Y'    @ERROR
            GOTO ENDVAL         (Uhm......)
            ENDIF
* This would never do 
  BLUSKY    IFNE 'BLUE'         
            MOVE 'Y'    @ERROR
            GOTO ENDVAL         
            ENDIF
* Gotta have this on file 
  RECKEY    CHAINVALFREC                  99
  *IN99     IFEQ *ON
            MOVE 'Y'    @ERROR
            GOTO ENDVAL
            ENDIF
<etc. etc. etc.>
  ENDVAL    ENDSR
**********************************************
Well, now that I have this off my chest, guess I'll just mosey
on over and brew some DECAF.

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