>     01  Hundreds                PIC   9 Value Zeros.
>     01  Tens                    PIC   9 Value Zeros.
>     01  Ones                    PIC   9 Value Zeros.
>     01  Test-Number             PIC 999 Value Zeros.
[...]
>     Perform Tester
>         Varying Hundreds from 1 by 1 Until Hundreds > 9
>             After Tens from 0 by 1 Until Tens > 9
>                 After Ones from 0 by 1 Until Ones > 9.
[...]
> I don't think I handled the varying clause correctly . . . I need the
> digits to hit and include '9' before stopping but what happens when
> they hit '10' but are only PIC 9s

>         String  Hundreds delimited by size
>                 Tens delimited by size
>                 Ones delimited by size
>           Into  Test-Number.

>         Compute Test-Case = (Hundreds * Hundreds * Hundreds) +
>                             (Tens * Tens * Tens) +
>                             (Ones * Ones * Ones).

>         If Test-Case = Test-Number
>             Display Test-Number ' is a perfect number'
>             Add 1 to Perfect-Number-Counter.

>>I took an examination in my COBOL class earlier this evening and was troubled by
>>one of the test questions.  I know it's one of those "too easy to be easy" questions.

>>If it's not out of line, I thought I would post the question and my thoughts on it,
>>then ask for feedback.

>>Question (from memory):  A perfect number is a number which is equal to the cube
>>of its component digits summed -- that is, 153 is a perfect number because it is
>>equal to 1*1*1 + 5*5*5 + 3*3*3.  Code a COBOL program to find the perfect numbers
>>between 100 and 999.

>>I came up with this, but I'm not convinced that this is the right approach -- beyond
>>the apparent problems with this code itself.

>snip...snip...

>try
>01 my-number pic 9999.
>01 filler redefines my-number.
>   05 filler pic 9.
>   05 my-hun pic 9.
>   05 my-dec pic 9.
>   05 my-one pic 9.

>perform varying my-number from 100 by 1 until my-number = 1000
>   ....
>   compute test-num = my-hun ** 3 + my-dec ** 3    etc.

>JR

>and stir with a Runcible spoon...

> >    01  Test-Number   PIC  9(3).
> >    01  Filler        Redefines Test-Number.
> >        05  Hundreds  PIC  9(1).
> >        05  Tens      PIC  9(1).
> >        05  Ones      PIC  9(1).

> >    Perform Tester
> >        Varying Test-Number from 100 by 1 Until Test-Number = ZERO.

> Maybe we should say BY -1 here instead of BY 1; it might help making
> progress towards termination.

>>I took an examination in my COBOL class earlier this evening and was troubled by
>>one of the test questions.  I know it's one of those "too easy to be easy" questions.

>>If it's not out of line, I thought I would post the question and my thoughts on it,
>>then ask for feedback.

>>Question (from memory):  A perfect number is a number which is equal to the cube
>>of its component digits summed -- that is, 153 is a perfect number because it is
>>equal to 1*1*1 + 5*5*5 + 3*3*3.  Code a COBOL program to find the perfect numbers
>>between 100 and 999.

>JR

>and stir with a Runcible spoon...

>>     01  Hundreds                PIC   9 Value Zeros.
>>     01  Tens                    PIC   9 Value Zeros.
>>     01  Ones                    PIC   9 Value Zeros.
>>     01  Test-Number             PIC 999 Value Zeros.
>[...]
>>     Perform Tester
>>         Varying Hundreds from 1 by 1 Until Hundreds > 9
>>             After Tens from 0 by 1 Until Tens > 9
>>                 After Ones from 0 by 1 Until Ones > 9.
>[...]
>> I don't think I handled the varying clause correctly . . . I need the
>> digits to hit and include '9' before stopping but what happens when
>> they hit '10' but are only PIC 9s

>Think of each "9" in a picture as one wheel in your car's odometer.  The
>value 9 rolls over to the value 0.  For example, in this program the
>variable ONES will take on the values 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1,
>2, ...

>ONES can never be greater than 9, so TENS will never be incremented.
>TENS can never be greater than 0, so HUNDREDS will never be incremented.
>HUNDREDS can never be greated than 1 so your loop will never terminate.
>TEST-NUMBER will take on the values 100, 101, 102, 103, 104, 105, 106,
>107, 108, 109, 100, 101, ...

>All those 01-levels indicate that you are not yet comfortable with
>CoBOL's hierarchical structure.  Consider this:

>    01  Test-Number   PIC  9(3).
>    01  Filler        Redefines Test-Number.
>        05  Hundreds  PIC  9(1).
>        05  Tens      PIC  9(1).
>        05  Ones      PIC  9(1).

>    Perform Tester
>        Varying Test-Number from 100 by 1 Until Test-Number = ZERO.

>>         Compute Test-Case = (Hundreds * Hundreds * Hundreds) +
>>                             (Tens * Tens * Tens) +
>>                             (Ones * Ones * Ones).

>>         If Test-Case = Test-Number
>>             Display Test-Number ' is a perfect number'
>>             Add 1 to Perfect-Number-Counter.

>One thing about any computer language, including CoBOL, is that it will
>cheerfully do whatever you say.  Consider this:

>    Tester.

>        If   Hundreds * Hundreds * Hundreds
>        +    Tens * Tens * Tens
>        +    Ones * Ones * Ones
>    =    Test-Number
>        Then Display Test-Number ' is a perfect number'
>             Add 1 to Perfect-Number-Counter
>        End-if.

>There's still a long way to go from here to a good program, but at least
>this one terminates!  Remember, programing is not knowledge acquired by
>memorization, it is skill acquired by practice.  These little problems
>are posed merely to give you a reason to grapple with the syntax until
>you have it at your fingertips, not to find the answers, which are, of
>course, well known.

>--
>Christopher Westbury, Midtown Associates, 15 Fallon Place, Cambridge, MA 02138

> > >    01  Test-Number   PIC  9(3).
> > >    01  Filler        Redefines Test-Number.
> > >        05  Hundreds  PIC  9(1).
> > >        05  Tens      PIC  9(1).
> > >        05  Ones      PIC  9(1).

> > >    Perform Tester
> > >        Varying Test-Number from 100 by 1 Until Test-Number = ZERO.

> > Maybe we should say BY -1 here instead of BY 1; it might help making
> > progress towards termination.

> Couple of things at once here.

> First, on the 'perfect number' issue I stand corrected.  Even Webster's
> Dictionary gets this right -- and I didn't.

> Second, thanks to all who made suggestions about my code.  I admitted
> up front that knew I blew this one on the test.  As usual, I was bent
> on making things more difficult than they needed to be.  The posts
> suggested some straightforward, solid and _simple_ ways to handle the
> problem.  I learned, and I thank you.

> Finally, the +1 increment (as opposed to a -1 decrement) does work.
> The code below is exported directly from my compiler; it is verbatim
> except for changing references to "perfect numbers" :)  It compiles
> and runs without error, displaying four numbers.

>        IDENTIFICATION DIVISION.
>        Program-ID.              NotPerfectNumbers.

>        DATA DIVISION.
>        Working-Storage Section.
>        01  Test-Num            PIC 999.
>        01  Test-Digits Redefines Test-Num.
>            05  Huns            PIC 9.
>            05  Tens            PIC 9.
>            05  Ones            PIC 9.

>        Procedure Division.
>        Mainline.
>            Perform Varying Test-Num from 100 by 1 Until Test-Num = 000
>              If ((Huns ** 3) + (Tens ** 3) + (Ones ** 3)) = Test-Num
>                Display Test-Num ' is not a perfect number'
>                  End-if
>                    End-Perform.

> My thinking is that this works because the +1 increment causes the
> value '1000' to be placed in the Test-Num field but, because of
> COBOL's right-to-left movement of numbers, only the last three digits
> are stored in the field.

> Thus, the '= 000' test works.

> Thanks again to all who posted.

> John Streeter

>> > >    01  Test-Number   PIC  9(3).
>> > >    01  Filler        Redefines Test-Number.
>> > >        05  Hundreds  PIC  9(1).
>> > >        05  Tens      PIC  9(1).
>> > >        05  Ones      PIC  9(1).

>> > >    Perform Tester
>> > >        Varying Test-Number from 100 by 1 Until Test-Number = ZERO.

>> > Maybe we should say BY -1 here instead of BY 1; it might help making
>> > progress towards termination.

>> Couple of things at once here.

>> First, on the 'perfect number' issue I stand corrected.  Even Webster's
>> Dictionary gets this right -- and I didn't.

>> Second, thanks to all who made suggestions about my code.  I admitted
>> up front that knew I blew this one on the test.  As usual, I was bent
>> on making things more difficult than they needed to be.  The posts
>> suggested some straightforward, solid and _simple_ ways to handle the
>> problem.  I learned, and I thank you.

>> Finally, the +1 increment (as opposed to a -1 decrement) does work.
>> The code below is exported directly from my compiler; it is verbatim
>> except for changing references to "perfect numbers" :)  It compiles
>> and runs without error, displaying four numbers.

>>        IDENTIFICATION DIVISION.
>>        Program-ID.              NotPerfectNumbers.

>>        DATA DIVISION.
>>        Working-Storage Section.
>>        01  Test-Num            PIC 999.
>>        01  Test-Digits Redefines Test-Num.
>>            05  Huns            PIC 9.
>>            05  Tens            PIC 9.
>>            05  Ones            PIC 9.

>>        Procedure Division.
>>        Mainline.
>>            Perform Varying Test-Num from 100 by 1 Until Test-Num = 000
>>              If ((Huns ** 3) + (Tens ** 3) + (Ones ** 3)) = Test-Num
>>                Display Test-Num ' is not a perfect number'
>>                  End-if
>>                    End-Perform.

>> My thinking is that this works because the +1 increment causes the
>> value '1000' to be placed in the Test-Num field but, because of
>> COBOL's right-to-left movement of numbers, only the last three digits
>> are stored in the field.

>> Thus, the '= 000' test works.

>> Thanks again to all who posted.

>> John Streeter

>Until somebody modifies your code,  too many maintenance programmers
>have lost sleep trying to figure what is causing a program to go down,
>with the original programmer being a little to clever to keep it simple.
>3 am logic is going to say "Why on earth is he adding to field and then
>comparing it to zero". I know of no program that has never undergone
>modification for some change in functionality, that count field may well
>be used for some other reason later, it could be expanded, used as a
>subscript, whatever.  KISS is a rule of thumb all programmers should
>adhere to, if just for the poor guy on call at night.

>> THERE  IS  NO  GOOD  SOLUTION.

>What about this one?

>01  Test-Num    pic 9(4).
>01  filler redefines Test-Num.  
>     05  filler     pic x.
>     05  Hundreds   pic 9.
>     05  Tens       pic 9.  
>     05  Ones       pic 9.

>You can now use 'until Test-Num > 999'