Declaring variables in COBOL

Question

I'm sorry if this question has been already answered, I've tried to search all over this site and I couldn't find anything.

I created a calculator that receives value and option from Mainframe Replies and then does the arithmetic operations.

My main problem is that if I declare a pic 9(3) and the value is 2 it'll display this way: 200 instead of 2.

How could I format this in order to avoid this problem?

Thank you!

Answer 1

For several reasons, I suggest something along these lines rather than what has already been suggested: your input field is short, so no real problem with dealing with individual names for three fields; you need to validate the input before calculating; it'll give you some practice with COBOL field definitions; it is the way I'd do it for this case (short, simple-format, data, requiring validation).

The procedure code is simple, and can be structured in any number of ways.

Your data may be: 4+ characters (invalid), zero characters (invalid), three characters, two characters, one character, and must be numeric (you haven't mentioned it is a Hex Calculator) for these last three, otherwise invalid.

Make the procedure code reflect that.

To keep things simple, deal with the major invalid data first (too long, too short) and don't let that near the rest of the processing.

With those out of the way, it is easy to identify input of one character (two trailing spaces) then two characters (now the only remaining possibility when space in third position) then what is left must be three characters.

Having given each field an individual name, they can be tested for NUMERIC in their own piece of code (I like to de-clutter IF/EVALUATE by using PERFORM, but many don't) and simply MOVEd to a PIC 999/9(3) field if valid.

The PIC 999/9(3) field can be defined as COMP-3/PACKED-DECIMAL. An alpha-numeric (PIC X...) field can be moved directly to that. The reason you may want to do this is because we know for sure it is going in to a calculation, which means the compiler will have to convert it to packed-decimal anyway, so you can consider the conversion up-front. If all other fields in your calculation are binary, you could subsequent to the first MOVE, do a second move to a COMP/COMP-4/BINARY/COMP-5 field (you cannot directly MOVE a PIC X... to a binary field).

01  INPUT-LINE.
    05  INPUT-VALUE.
        88  IV-NO-VALUE          VALUE SPACE.
        10  IV-THREE-DIGITS.
            15  IV-TWO-DIGITS.
                20  IV-ONE-DIGIT PIC X.
                20  FILLER       PIC X.
            15  FILLER           PIC X.
                88  IV-ONE-TRAILING-BLANK 
                                 VALUE SPACE.
    05  FILLER REDEFINES INPUT-VALUE.
        10  FILLER               PIC X.
        10  FILLER               PIC XX.
            88  IV-TWO-TRAILING-BLANKS 
                                 VALUE SPACE.
    05  FILLER                   PIC X(77).
        88  IV-NO-EXTRA-DATA     VALUE SPACE.

01  INPUT-VALUE-FOR-CALCULATION  PIC 9(3).

PERFORM VALIDATE-INPUT
VALIDATE-INPUT.
    IF IV-NO-EXTRA-DATA
        EVALUATE TRUE
          WHEN IV-NO-VALUE
            set some unique error
          WHEN IV-TWO-TRAILING-BLANKS
            PERFORM ONE-INPUT-CHARACTER
          WHEN IV-ONE-TRAILING-BLANK
            PERFORM TWO-INPUT-CHARACTERS
          WHEN OTHER
            PERFORM THREE-INPUT-CHARACTERS
        END-EVALUATE
    ELSE
        set some unique error
    END-IF
ONE-INPUT-CHARACTER.
    IF IV-ONE-DIGIT NUMERIC
        MOVE IV-ONE-DIGITS TO INPUT-VALUE-FOR-CALCULATION
    ELSE
        set some unique error
    END-IF
TWO-INPUT-CHARACTERS.
    IF IV-TWO-DIGITS NUMERIC
        MOVE IV-TWO-DIGITS TO INPUT-VALUE-FOR-CALCULATION
    ELSE
        set some unique error
    END-IF
THREE-INPUT-CHARACTERS.
    IF IV-THREE-DIGITS NUMERIC
        MOVE IV-THREE-DIGITS TO INPUT-VALUE-FOR-CALCULATION
    ELSE
        set some unique error
    END-IF

You're a beginner, so you haven't wondered exactly why you ended up with 200.

ACCEPT, on the Mainframe, does not do numeric alignment, because ACCEPT is actually taking all the data that is available, slapping it into your field, and truncating any excess.

So that will get you 2 (that is two trailing blanks). Your field is PIC 999/9(3), so it is unsigned. Because it is unsigned the compiler will ensure that it is so when it is used as the source of a VERB. This will give you 2 0, because the left-hand part of the third byte (on the Mainframe) will be set to F from 4. X'40' is a space, which it was originally. X'F0' is zero, which is what you get when the 4 is changed to an F.

You still have that space in the middle. However, by the time you use that field for a calculation, all the left-parts of each byte (except the sign in the final one) will be stripped out to "pack" the field, and to put a result back in a PIC 999/9(3) Fs will simply be inserted as part of the "unpack". Lo, your two followed by two blanks is now 200!