HP3000-L Archives

March 1998, Week 1

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Therm-O-Link <[log in to unmask]>
Reply To:
Therm-O-Link <[log in to unmask]>
Date:
Wed, 4 Mar 1998 17:06:40 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (81 lines)
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

ATOM RSS1 RSS2