It was my impression that "Paragraph" recursion was not supported but
do-able, but that "procedure" or "subroutine" recursion was.  The reasoning
was that COBOL gave only a finite amount of room for tracking "performs"
but that it was the operating system and the program stack that controlled
procedure "calls".

Marshall Medoff
ITA, Inc.
Arlington, Virginia

______________________________ Reply Separator _________________________________
Subject: Recursion Supported?
Author:  Therm-O-Link <[log in to unmask]> at Internet
Date:    3/4/98 5:06 PM


On Wed, 4 Mar 1998 13:47:48 -0800, Glenn Cole writes:

>     Can you provide an example of *why* you need to perform a paragraph
>     recursively, especially given that there is no such thing as
>     "variables local to a given paragraph"??

But, of course!  We are a manufacturer of copper wire and cable.  One of
our customers asked for a report listing (by month, product type, and
gage) footage and weight of products.  To do this, I scan the invoice
detail file and calculate the weight from the bill-of-material file
(basically there are two components to a wire: copper stranding and
polymer insulation).  The problem occurs when I find what we call
a multi-conductor cable (it has several single conductors wrapped up
in a jacket - think about a trailer wiring harness).  In this case,
I get the components and then need to get the components' components
and add all this together to get the weight.  I would like the code
to look like this:

 S140-CALC-POUNDS.
     %PRD001FN1(PROD-NO-IND002#).       /* FIND COMPONENTS BY PRODUCT
NUMBER

     %PRD001CF.                         /* CHAIN FORWARD READ

     PERFORM S141-CALC-POUNDS
             UNTIL RECORD-NOT-FOUND-PRD001.

 S141-CALC-POUNDS.
     IF   PRESSURE-PRD001               /* POLYMER COMPOUND
       OR TUBED-PRD001
         PERFORM S142-CALC-COMPOUND

     ELSE
     IF CU-INNER-PRD001                 /* COPPER STRANDING
         PERFORM S143-CALC-COPPER

     ELSE
     IF MULT-INNER-PRD001               /* MULTI-CONDUCTOR
         PERFORM S144-CALC-INNER.

     %PRD001CF.                         /* CHAIN FORWARD READ

 S142-CALC-COMPOUND.
        <DO COMPOUND WEIGHT CALCS>

 S143-CALC-COPPER.
        <DO COPPER WEIGHT CALCS>

 S144-CALC-INNER.
     MOVE STAT3-4-DB             TO RECORD-NO-DB.       /* SAVE REC#

     %PRD001FN1(BOM-PROD-NO-PRD001#).   /* FIND BY COMPONENT PRODUCT

     %PRD001CF.                         /* CHAIN FORWARD ON NEW CHAIN

     PERFORM S141-CALC-POUNDS
             UNTIL RECORD-NOT-FOUND-PRD001.

     %PRD001FN1(PROD-NO-IND002#).       /* FIND BY PARENT PRODUCT

     %PRD001DR(RECORD-NO-DB#)           /* RESET CHAIN TO SAVED REC#


Well, what do you think?  Maybe this isn't recursion at all?  But
the perform chain looks like this:

S141 -> S144 -> S141

That looks like recursion to me.  I went ahead and coded the program
without recursion (it's clearer that way), but I still would like to
know if I could have done it differently.

BTW, there is no chance at all (sure, sure!) that S141 could call S144
again for the same product; that is, we never have a multi-conductor
as a component of a multi-conductor, at least not yet!

Jim Phillips                            Manager of Information Systems
E-Mail: [log in to unmask]      Therm-O-Link, Inc.
Phone: (330) 527-2124                   P. O. Box 285
  Fax: (330) 527-2123                   Garrettsville, Ohio  44231