Visual COBOL numeric variables issue

We recently moved from MF COBOL to Visual COBOL(Eclipse). When we were doing testing between MF COBOL and Visual COBOL we identified few differences in the extracts which are generated. In numeric variables the trailing zeros are missing in visual cobol

eg:

MF COBOL: 9848300

Visual COBOL: 98483

Whether i need to change any compiler option, so that this issue will be solved?

Parents Reply Children
  • The variable is defined 9(09) . We assumed NOTRUNC compiler option will solve this issue but it didnt.

    Can you please suggest what needs to be changed?

  • Please answer Fano's 2nd question so that we can formulate a response:

    How does the numeric field receive the value?

    Are you using an ACCEPT statement, a MOVE statement, a READ from file, etc??

    Thanks.

  • We are using move statement to copy the value into a variable and write into a file.
  • Please provide some detail or an example so we can try to test this.

    What product and version number is this and what is the OS being used?
    What does the sending field look like and what is its value? Is it 98483 or 9848300?

    Where are the zeroes being stripped, on the move to the receiving field or after writing the data to the file?

    Can you please show me the move statement and indicate where you see the problem?

    Thanks.

  • For example consider this move from INPUT to OUTPUT field.

    Variable Declaration

    01 WS-INPUT-FIELD PIC X(09) VALUE SPACES.
    01 WS-OUTPUT-FIELD PIC 9(09) VALUE ZEROES.

    Move Statements:

    MOVE '83728' TO WS-INPUT-FIELD
    DISPLAY '****' WS-INPUT-FIELD '****'.
    MOVE Ws-INPUT-FIELD To WS-OUTPUT-FIELD.
    DISPLAY '****' WS-OUTPUT-FIELD '****'.

    Output in MF COBOL compiled in NET Express 3.1

    ****83728    ****
    ****837280000****

    Net Express->Project->Properties->Project Directives

    %FILENAME COBIDY(%TARGETDIR) WB3 WB CSI ANIM EDITOR(MF2) ENSUITE(3)

    Output in Visual COBOL 4.0 in Eclipse

    ****83728    ****
    ****83728    ****

    Eclipse->Project->Properties->Micro Focus->Project Settings->COBOL

    XREF SETTING PERFORM-TYPE(VSC2) ASSIGN(EXTERNAL) CHANGE-MESSAGE(1890 W 1891 W)

     

    Whether i can add a compiler directive to make visual cobol behave the same way as NET express output or i need make some changes in my code? Please suggest


    Please let us know if you need any other information

  • Verified Answer

    What you are dealing with here is the case of invalid numeric data because a numeric field contains space characters. The default behavior is that the results are "undefined".

    I can get the same behavior as Net Express at least in this small demo that you provided by adding either the SPZERO or SIGN-FIXUP directives to the compile.

    Depending on the compatibility of the results of undefined behavior is risky as there is no guarantee that the results will be reproducible in subsequent product versions.

    It would be better practice to not allow the space characters into the numeric fields to begin with.

    Thanks.

  • Senthil4,

    As Chris has explained above, your code is relying on undefined behavior. The following is from the documentation of the MOVE statement :

    When the receiving item is numeric or numeric-edited and the sending item is defined as alphanumeric, if the content of the sending item is not an integer, the results of the move are undefined.

    You could try adding

    01 WS-DIGITS PIC 9(9) COMP.

    and changing your code to something like this :

    MOVE '83728' TO WS-INPUT-FIELD
    DISPLAY '****' WS-INPUT-FIELD '****'
    MOVE 0 TO WS-DIGITS
    INSPECT WS-INPUT-FIELD TALLYING WS-DIGITS
        FOR CHARACTERS BEFORE SPACE
    IF WS-DIGITS NOT EQUAL ZERO AND
        WS-INPUT-FIELD(1:WS-DIGITS) IS NUMERIC
        MOVE WS-INPUT-FIELD(1:WS-DIGITS) TO  
                      WS-OUTPUT-FIELD(1:WS-DIGITS)
    END-IF
    DISPLAY '****' WS-OUTPUT-FIELD '****'

    That will ensure that only numeric values are copied to WS-OUTPUT-FIELD.

    Gael

  • Thanks Chris. I will suggest my team on your recommendation and we will try to fix the numeric data instead adding compiler directive