Re: Recursive Call


"Judson McClendon" <judmc@xxxxxxxxxxxxx> wrote in message
news:lNOaf.14$%k.4@xxxxxxxxxxxxxxxxxxxxxxxxx
> "Chuck Stevens" <charles.stevens@xxxxxxxxxx> wrote:
>> Note that within COBOL that is compliant with the three most recent
>> standards, both direct and indirect recursion is prohibited. If an
>> implementor allows it (or provides additional syntax to support it), it's
>> an extension and it does whatever the implementor says it does.
>
> Why in the world would recursion be forbidden? I haven't used it often in
> COBOL, but I did find it extremely useful in writing a parts explosion
> module once. The code, which was pretty elegant, would have been somewhat
> tacky without recursion.

While recursion isn't a big issue for stack-oriented machines like the
Unisys MCP systems -- on which the compiler has to go to the trouble to
generate code to *prevent* recursion -- I believe there was some reluctance
on the part of J4 to require it until it could be ascertained what the
pitfalls were and what the appropriate syntax was.

The initial specification of Inter-Program Communication was in '74 COBOL,
and my guess is the approach was "wait and see how it shakes out".

The *second* specification added nested programs, which was a significant
advancement, and again, enough syntax was added to raise the question as to
whether adding recursion would break something.

Since our systems fundamentally support recursion, and since it's a common
technique in ALGOL and related languages, I am led to suggest that the
technique must be used very carefully. The impact of a runaway loop in a
recursive environment can be significantly greater and can cause escalating
resource consumption in ways that an "ordinary" runaway loop wouldn't.
COBOL doesn't (yet) have a standardized mechanism for asynchronous
processing, either (our COBOL85 does, and I happen to think the syntax
involving USAGE EVENT and USAGE LOCK is clean and clear), and I think
similar issues occur there. It becomes the programmer's responsibility to
protect the data for each user in a multithreaded program, and the issues
there can easily get very sticky very quickly on efficiency, security, and
effectiveness grounds.

-Chuck Stevens


.

Relevant Pages

  • Re: CoBOL moved to OO
    ... the single thing that distinguishes old old old COBOL from all of the ... Programming with any language that allows recursion is definitely a paradigm ... of new things are possible with that alone (way short of use of the new syntax ... Yet Class methods and data are part of object orientation. ...
    (comp.lang.cobol)
  • Re: CoBOL moved to OO
    ... that we shopuld be considering how to help COBOL people bridge the gap. ... > languages that descend from ALGOL is that COBOL resisted recursion until ... But it is notable that RECURSIVE program ID syntax enters COBOL ... Yet Class methods and data are part of object orientation. ...
    (comp.lang.cobol)
  • Re: CoBOL moved to OO
    ... RECURSION was added in the 2002 Standard. ... support to it for COBOL was only ... Yet Class methods and data are part of object orientation. ...
    (comp.lang.cobol)
  • Re: free implementation? factorial?
    ... >> Alain Reymond wrote: ... >>>Try to use the recursive posssibilities of modern Cobol. ... >> using recursion is preferable. ... the practical programmer/designer, a sort of "Ockham's Razor" approach ...
    (comp.lang.cobol)
  • Re: CoBOL moved to OO
    ... COBOL compilers were always code (not data, ... this is easier to do with stack ... The Burroughs/Unisys Large ... a 'stack' to handle the data recursion. ...
    (comp.lang.cobol)