Recursive performs are certainly not forbidden, but are rare. I once used
one as the target paragraph of the ON OVERFLOW clause of STRING operation.
A100-CONTINUE.
. . . a lot of stuff omitted . . .
PERFORM
VARYING WORD-IX FROM WORD-IX BY +1
UNTIL WORD-IX > +100
OR INPUT-WORD (WORD-IX) = SPACES
MOVE INPUT-WORD (WORD-IX) TO WS-WORD
STRING WS-WORD
DELIMITED BY SPACES
SPACE
DELIMITED BY SIZE
INTO OUTPUT-LINE
WITH POINTER WS-CHAR-OUT-PTR
ON OVERFLOW
PERFORM A100-CONTINUE
END-STRING
END-PERFORM
.
On Mon, Apr 25, 2011 at 16:56, Frank Swarbrick <
[email protected]> wrote:
> Couple questions....
>
> What do you mean that a recursive PERFORM is forbidden? While I can't
> think of a good use for it, and when I tried it I got into a loop, it
> doesn't cause a compile or run-time error.
> Here's what I tried:
>
> identification division.
> program-id. recur.
> data division.
> working-storage section.
> 77 x pic 9(4) comp value zero.
>
> procedure division.
> perform para
> goback.
>
> para.
> add 1 to x
> display x
> if x < 3
> display 'before'
> perform para
> display 'after'
> else
> display 'no'
> end-if
> display 'end'
> .
>
>
> 0001
> before
> 0002
> before
> 0003
> no
> end
> after
> end
> after
> end
> after
> end
> ...and on and on and on...
>
> So while it doesn't "work", neither is it apparently disallowed.
>
> In any case, I wonder if it would be useful to open a PMR to see if they
> have any suggestions on how to debug your issue. It's an interesting issue,
> and in my 15 years of COBOL programming I don't think I've ever had a case
> where I had to debug such a thing. Lucky perhaps?
>
> Can this issue not be reproduced in a test/dev region?
>
> I'm surprised it's up to a sysprog to figure out this issue. I don't think
> my sysprogs would touch COBOL with a ten foot pole. :-) They'd shoot us if
> we (appl dev) gave this to them to resolve. And rightly so.
>
> Frank
>
> --
>
> Frank Swarbrick
> Applications Architect - Mainframe Applications Development
> FirstBank Data Corporation - Lakewood, CO USA
> P: 303-235-1403
>
>
> On 4/25/2011 at 1:49 PM, in message
> <[email protected]>,
> "McKown,
> John" <[email protected]> wrote:
> > It is possible to enter a paragraph in either way: You can PERFORM a
> section,
> > paragraph, or series of paragraphs (A THRU B). It is possible, but
> unlikely
> > to have:
> >
> > A.
> > ...code
> > PERFORM B THRU D.
> > PERFORM C.
> > ...
> > GOBACK.
> > B. code
> > ... more code in B
> > C. code
> > ... more code in C
> > D. code
> > ... more code in D
> > E.
> >
> > Now, assume that some statement in C causes an abend. Was it from the
> first
> > PERFORM, where it just got "dropped into" on the way from B to D? Or was
> it
> > the second PERFORM where it was directly PERFORM'd from paragraph A? I
> will
> > admit that this code sequence is unlikely. But I don't really care. This
> is
> > for my learning and whining pleasure <grin>. We don't having anything
> this
> > unusual. What we have is more like one paragraph which reads a file. That
> is
> > all it does. But it is PERFORMed from 6 different paragraphs. Which are
> > themselves PERFORMed from more than one other paragraph each. We get a
> loop
> > (in CICS to be exact) and I cancel the transaction. I am almost always in
> > that "read" paragraph. With no idea where I came from, so doing
> diagnostics
> > is difficult. And putting in "tracing" entries in production CICS code
> when
> > we are "screamed" at about the "inordinate cost to run the z" is just not
> > politically acceptable.
> >
> > --
> > John McKown
> > Systems Engineer IV
> > IT
> >
> > Administrative Services Group
> >
> > HealthMarkets(r)
> >
> > 9151 Boulevard 26 * N. Richland Hills * TX 76010
> > (817) 255-3225 phone *
> > [email protected] * www.HealthMarkets.com
> >
> > Confidentiality Notice: This e-mail message may contain confidential or
> > proprietary information. If you are not the intended recipient, please
> > contact the sender by reply e-mail and destroy all copies of the original
> > message. HealthMarkets(r) is the brand name for products underwritten and
> > issued by the insurance subsidiaries of HealthMarkets, Inc. -The
> Chesapeake
> > Life Insurance Company(r), Mid-West National Life Insurance Company of
> > TennesseeSM and The MEGA Life and Health Insurance Company.SM
> >
> >
> >
> >> -----Original Message-----
> >> From: IBM Mainframe Discussion List
> >> [mailto:[email protected]] On Behalf Of Tobias Schmid
> >> Sent: Monday, April 25, 2011 2:32 PM
> >> To: [email protected]
> >> Subject: Re: Recursive PERFORM in COBOL
> >>
> >> > What triggered this is a desire on my part to __EASILY__
> >> detemine the
> >> > PERFORM sequence that got me to a particular paragraph.
> >> Right now, I
> >> > must find the "PERFORM return" slot for the paragraph in
> >> execution to
> >> > determine which paragraph the PERFORM verb is in. And then
> >> "loop" doing
> >> > the same. And I'm not sure how to determine if a paragraph
> >> was truly
> >> > PERFORM'ed as opposed to "dropped into" from the preceeding
> >> paragraph.
> >> > Some sort of "stack" would make this much simpler for me.
> >>
> >>
> >> I think the problem comes with the "dropped into".
> >> There should be no way, to "drop" into a paragraph - but if so,
> >> then there are goto's - where only performs should be.
> >>
> >> Or have I missunderstood something?
> >>
> >> Tobias Schmid
> >>
> >> ----------------------------------------------------------------------
> >> For IBM-MAIN subscribe / signoff / archive access instructions,
> >> send email to [email protected] with the message: GET IBM-MAIN INFO
> >> Search the archives at http://bama.ua.edu/archives/ibm-main.html
> >>
> >>
> >
> > ----------------------------------------------------------------------
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to [email protected] with the message: GET IBM-MAIN INFO
> > Search the archives at http://bama.ua.edu/archives/ibm-main.html
>
> >>>
>
> The information contained in this electronic communication and any document
> attached hereto or transmitted herewith is confidential and intended for the
> exclusive use of the individual or entity named above. If the reader of
> this message is not the intended recipient or the employee or agent
> responsible for delivering it to the intended recipient, you are hereby
> notified that any examination, use, dissemination, distribution or copying
> of this communication or any part thereof is strictly prohibited. If you
> have received this communication in error, please immediately notify the
> sender by reply e-mail and destroy this communication. Thank you.
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
