Indeed, Victor, you are quite correct! And as soon as Enterprise COBOL
supports user-written functions I will start using them!
FWIW, I don't think your code would work as-in even then, because END-PERFORM
is only for inline performs, but you are doing an "out of line" perform. You'd
really have to use one of the following:
PERFORM PROCESS-MY-RECORD
UNTIL GET-NEXT-REC(NEXT-RECORD) = 0
PERFORM UNTIL GET-NEXT-REC(NEXT-RECORD) = 0
PERFORM PROCESS-MY-RECORD
END-PERFORM
The first option, even if it works, looks (to me) "a bit weird", because
structurally it looks like PROCESS-MY-RECORD is done prior to GET-NEXT-REC(),
so I would stick with the second option; even if its a bit more verbose.
Now that I think about it, though, I'm not sure if this would work. The above
assumes that function GET-NEXT-REC not only returns a result, where 0 means
"end of file", but it also assumes that the parameter is passed by reference
and can be updated by the function. Are we sure the COBOL standard allows for
that? I'll look at some point, but not right this.
Frank
________________________________
From: IBM Mainframe Discussion List <[email protected]> on behalf of
Victor Gil <[email protected]>
Sent: Thursday, July 14, 2016 8:04 AM
To: [email protected]
Subject: Re: Considering Enterprise COBOL 5.2 "exit" enhancements
Frank,
It should be quite easy to achieve what you want by introducing user-written
FUNCTIONs, callable by name [i.e. NOT via CALL "xyz" verb]
Consider the below code:
PERFORM PROCESS-MY-RECORD
UNTIL GET-NEXT-REC(NEXT-RECORD) = 0
END-PERFORM
Here GET-NEXT-REC is a FUNCTION name which returns the number of gotten records
on a subsequent read attempt [either 0 or 1] and when successful also populates
a passed area with the just read record.
This is how I was coding this type of logic in the old PL/I for DOS.
Unfortunately, with all new features Cobol still does not allow for such syntax
[unless I missed the enhancement].
-Victor-
======================================================================
Hi, it's me.
My general thoughts are:
- This type of syntax is supported in a host of other programming languages.
(see below for examples)
- Is it really confusing? For me its more confusing doing all the things that
I've done up to this point because COBOL (prior to the 2002 standard) did not
allow me to do what I really wanted.
- I also think the elimination of procedure division SECTIONS and the
"performing" of multiple paragraphs (PERFORM...THRU) by using these new
features can be quite a benefit, rather than an issue. Now will some people
use/misuse these constructs within the context of sections and PERFORM THRU.
Certainly. But any programming language syntax can be misused. That doesn't
mean they should be eliminated (well, except for the ALTER statement, perhaps!).
- In the end, to me these new language features *enhance* structured
programming.
https://www.rosettacode.org/wiki/Loops/Break
Loops/Break - Rosetta Code<https://www.rosettacode.org/wiki/Loops/Break>
www.rosettacode.org
Loops/Break You are encouraged to solve this task according to the task
description, using any language you may know.
break: C and its followers (C++, Java, C#), Delphi, JavaScript, Ruby, Python
leave: PL/I and REXX
last: Perl
exit: Ada
EXIT PERFORM: COBOL
https://www.rosettacode.org/wiki/Loops/Continue
continue: C and its followers (C++, Java, C#), Delphi, JavaScript, Python
iterate: PL/I and REXX
next: Perl, Ruby
[not supported]: Ada
EXIT PERFORM CYCLE: COBOL
I can't find a Rosetta Code page for early exit/return from a
procedure/function, but I believe the following are true:
return: C and its followers (C++, Java, C#), Delphi, JavaScript, Ruby, Python,
PL/I, Rexx, Perl
EXIT PARAGRAPH / EXIT SECTION: COBOL
Should COBOL have added new keywords instead of co-opting/enhancing EXIT? I
don't think so. Really, EXIT as COBOL defines it should never have existed.
If they wanted a word to represent the end of a procedure they should have used
the work END! (And they did in the 85 standard support END PROGRAM, so why not
END PARAGRAPH (too wordy, but...) and END SECTION. Oh well!)
One of my favorite examples of the use of EXIT PERFORM is the "elimination" of
"priming reads". It's bugged me for 20 years (my COBOL lifetime). To me, the
following is ideal
PERFORM UNTIL EXIT *> Not currently part of the COBOL standard!!! :-(
READ MY-FILE INTO MY-RECORD
AT END
EXIT PERFORM
NOT AT END
PERFORM PROCESS-MY-RECORD
END-READ
END-PERFORM
Here you have a read/process loop until such time as the read "fails",
whereupon you exit/terminate the loop.
Unfortunately "PERFORM UNTIL EXIT" is not part of the COBOL standard (though it
is supported as an extension by some implementations), so you have to come up
with a dummy field that will "never be true" (in which case the compiler can
optimize away the check), or your code can "check it twice" (once after the
read and once at the top of the loop), which is redundant.
Those are my thoughts for now. I have plenty more if anyone is interested.
:-)
Frank
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
