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



On 23 Jul 2013 14:51, 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?

I agree with the desirability for the ability to use LEAVE in a non-looping DO group. I was merely pointing out the restriction, as diagnosed in messages; having totally overlooked referring to the help text for the LEAVE command to find it even more clearly documented :-( as was pointed out by Scott.

While I am not particularly fond of the GOTO, I am willing to use them when they are useful and not overly fraught with potential difficulties [likely to be seen only with later modifications to the code]. The use of Monitor Message (MONMSG) versus use of feedback from a function call, I think makes the use of the GOTO more preferable\easier than some might prefer, if having /well-structured/ code [or otherwise described as code that is free of GOTOs] is desirable. And in this case [overlooking the fact that the original code seems easily modified instead, to just remove the redundancy] the code could probably somewhat safely be written using a GOTO, by having a LABEL established for the EndDo:

Do
chkobj ...
monmsg cpf9800 exec(goto err9800)
call ...
...
err9800: /* this label must remain with the EndDo */ +
EndDo

That is of course effectively the same as the LEAVE. The biggest problems for maintenance are the possibility of someone copying the line with the GOTO elsewhere, or adding a line before the EndDo such that the label becomes associated with that new line of code. Copying the Do-group somewhere else is not an issue; that will be diagnosed as a duplicate label, and hopefully piquing the curiosity of the coder to review all references. Moving the label in front of the EndDo to avoid the line continuation is an option to avoid an inserted line, but that may pose stylistic concerns [for aligning the Do\EndDo].

To eliminate the GOTO, the code might best maintain an effective error indicator, much like how use of a function invocation might have one naturally coding that way. In effect, making the code respond to return-codes versus messaging. Consider the following two CLP samples whereby the first changes to move the processing of CHKOBJ to a function call, and the second continues to use MONMSG after the inline CHKOBJ, but both change to eliminate the GOTO and use conditional logic based on an effective indicator:

dcl &Authorized *char 01 /* I think *LGL not allowed as RtnVal */
,,.
Do
callprc ChkForObj parm(...) RTNVAL(&Authorized)
/* effectively: chgvar &Authorized value( ChkForObj(...) ) */
If cond(&Authorized *eq '1') then(Do)
call ...
...
EndDo
EndDo

dcl &SkipCall *lgl
,,.
Do
chkobj ...
monmsg cpf9800 exec(chgvar &SkipCall '1')
If cond(*not &SkipCall) then(Do)
call ...
...
EndDo
EndDo


FWiW I think the restriction might exist in part, because all of the iterative control statements and the ITERATE itself were all going in together. All of the code for LEAVE and ITERATE would be specific to only new CLP sources; i.e. none of DOWHILE, DOFOR, or DOUNTIL existed before. Testing for non-looping Do-groups is limited to the compiler vs run-time; i.e. ensuring the compiler diagnosed them as errors, thus limiting the amount of testing. Additionally it could have arisen in part as a side effect from the difficulty of establishing an unambiguous CMDLBL(*CURRENT) for the LEAVE. While obvious with regard to DO groups that are standalone, most Do-groups are instead embedded in an IF\ELSE. Like a GOTO LabelName can easily cause problems when code is changed or copied, so too could a LEAVE in an IF, given an ELSE was added; i.e. previously having processing continued in the implied ELSE, after adding an ELSE the processing LEAVE likely would have been defined to continue after the DO groups of both the IF and the ELSE.? The question mark, because arguably [and documented as such, that] they are two distinct non-nested Do-groups; one as part of the THEN of the IF statement and the other as part of the ELSE which is its own separate statement. Thus there is a possibly valid argument that the LEAVE CMDLBL(*CURRENT) would properly go to the ELSE. If the CMDLBL() specification could extend to a LABEL for an IF versus a LABEL for a DO statement, and all of the DO\ENDDO under that IF were considered as one Do-group, then that could make a LEAVE in a non-looping Do-group seem somewhat reasonable [to me].

Regards, Chuck

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.