I think the first example illustrates a 'primed' do loop. Have
everything set before you enter processing. This is the way they taught
us back in the '70s. I have also seen this presented in COMMON
sessions.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Mark Murphy/STAR
BASE Consulting Inc.
Sent: Wednesday, July 24, 2013 10:01 AM
To: Midrange Systems Technical Discussion
Subject: Re: Leave outside of DO group???
Sometimes this principle causes unnecessary nesting or duplication of
code. Say you are reading a file. Do you have two read statements, or
do you introduce an extra level of nesting in the loop to avoid
processing after no record found?
read
do while not eof
process
read
end do
or
do until eof
read
if not eof
process
end if
end do
or short cut it
do while true
read
if eof then leave
process
end do
The best practices being violated are (respectively):
* do not repeat yourself
* minimize nesting
* only one in and only one out
So which would you choose? It really comes down to shop standard, and
any of these are easy enough to understand, but personally I find that
excessive nesting is the biggest culprit in making code unreadable.
Mark Murphy
STAR BASE Consulting, Inc.
mmurphy@xxxxxxxxxxxxxxx
-----John McKee <jmmckee@xxxxxxxxxxxxxx> wrote: -----
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
From: John McKee <jmmckee@xxxxxxxxxxxxxx>
Date: 07/23/2013 07:18PM
Subject: Re: Leave outside of DO group???
I'm confused. I had a teacher, years ago, who was adamant - one way in
and one way out. How is LEAVE considered structured? Violates the
teacher's rule, since there are now multiple ways that a loop could be
exited. His preferred method was to test at the top.
I don't mean to start an argument. Just trying to understand how
multiple exit paths is considered structured.
I have had to debug programs with multiple exit paths. Process was more
involved.
John McKee
On Tue, Jul 23, 2013 at 4:58 PM, Booth Martin <booth@xxxxxxxxxxxx>
wrote:
Could he do a NOT/Else with the NOt MonMsg... else leave?
On 7/23/2013 4:51 PM, Dan Kimmel wrote:
Still, I like the concept. It'd be a way to get out of a block of
code without a GOTO. The Do .. EndDo marks the block of code. Are there
other ways to jump out of a block in CL structured op codes?
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-
bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Tuesday, July 23, 2013 4:13 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Leave outside of DO group???
On 23 Jul 2013 13:48, DrFranken wrote:
I wrote this snippet of code:
Do
ChkObj QSTRUPEX1 *Pgm /* Check for exit program. */
MonMsg CPF9800 EXEC(Leave) /* Not there or Not Authorized */
Call QSTRUPEX1 /* Run it. */
MonMsg CPF0000
EndDo
At the LEAVE Statement I get this error:
* CPD0883 30 LEAVE command found outside of DO group.
But it sure appears to be inside a Do group to me!
Am I in error if I 'complain' to the fine folks in the land of IBM
i?
AFaIK the error is correct, and ...
The implied command label [CMDLBL(*CURRENT)] is, as worded in
the message CPD089A, is not "associated with an active DOWHILE,
DOUNTIL, or DOFOR group". The additional\second-level text of that
CPD0883 [e.g. as presented by F1=Help] should further state that
"The LEAVE command must be inside a DOWHILE, DOUNTIL, or DOFOR
command group."
FWiW: Coding the MONMSG CPF0000 as shown is not a good practice;
just as well remove the prior CHKOBJ and MONMSG to get effectively
the same results with less work.
--
Regards, Chuck
--
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take
a moment to review the archives at
http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
This message contains confidential information. If you are not the intended recipient you should not disseminate, distribute or copy this e-mail. Please notify sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. Any copyrighted material sent to you is for your own internal use only. Users are not permitted to modify, distribute, publish, transmit or create derivative works of any material found contained herein for any public or commercial purpose.
E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission.
midrange.com
