Fitting more than 18 digits in numeric field. 1

[mbkvmk]

Hi,

I have a requirement where I need to acommodate a number which is more 18 digits (20 actually including 6 decimal places) in to a 18 digit field. The version of COBOL we have, supports only 18 digits.

This field is part of an 80 byte record. I don't really want to try the most obvious option of dividing the number and then storing the divident & remainder in separate fields and then later multiplying & adding to get the actual number, due to the 80 byte restriction (out of which I can only use 40 due to the 1st 40 being occupied by the key).

Please let me know if you can think of a better non-complicated solution.

Thanks !

 

[webrabbit]

The 18-digit limit is not just your version. It is in the COBOL standard. The next version of the standard may relax that restriction. I can't imagine what that 20-digit number represents, as 18 digits is enough for the world economy down to the nearest Sen or Mil. So anyway, you are stuck with the 18-digit limit for now. Here is some sample code to process this 20-digit number:

Assuming the number is unsigned DISPLAY:

    01  20-BYTE-WORK-AREA.
        05  WORK-A          PIC 9(14).
        05  WORK-B          PIC V9(6).

    01  WORK-1              PIC 9(14)V9(4).
    01  REDEFINES WORK-1.
        05  WORK-1A         PIC 9(14).
        05  WORK-1B         PIC V9(4).

    01  WORK-2              PIC 9(12)V9(6).
    01  REDEFINES WORK-2.
        05  WORK-2A         PIC 9(12).
        05  WORK-2B         PIC V9(6).
    .
    .
    .
        MOVE record-field      TO 20-BYTE-WORK-AREA.
        MOVE WORK-A            TO WORK-1.
        MOVE WORK-B            TO WORK-2.
        do the computations on both WORK-1 and WORK-2.
        ADD WORK-1B            TO WORK-2.
        ADD WORK-2A            TO WORK-1A.
        MOVE WORK-1A           TO WORK-A.
        MOVE WORK-2B           TO WORK-B.
        MOVE 20-BYTE-WORK-AREA TO record-field.

If the field is signed or packed, it gets more complicated. If the field is binary, it is almost impossible. If anyone needs code for signed or packed, I can provide it. The code for binary depends on whether the field is big-endian or little-endian. I could probably come up with that code too, if someone really needs it.

 

[slade]

Hi WR,

The next version is here. Enterprise COBOL supports 31 digit numbers. It must be support for the Lira.

Regards, Jack.

 

[mfcobol2002]

try COMP-5 format.

Marcos Antonio de Souza
Brasil

 

[webrabbit]

slade, how many Lira to the Yen?

mfcobol2002, COMP-5 is just binary. How would that help?

 

[Lunker]

The IBM reference manual says that COBOL for OS/390 supports 31 digit numbers. Packed and zoned decimal numbers may contain up to 31 digits if you use the compiler option ARITH(EXTEND). I've never tried it (never needed a number that large), but the manual says it works.

 

[webrabbit]

That sounds right. The machine has always supported 31-digit packed.

 

[slade]

Hi Lunker,

Looked thru the Pgmr's Guide for COBOL for OS/390 & VM (see details below), but couldn't find any reference to 31 digits or ARITH(EXTEND). Where did you find it?

Thanx, Jack.

Title: COBOL for OS/390 & VM Programming Guide
Document Number: SC26-9049-01
Build Date: 10/30/97 17:35:24 Build Version: 1.3.0
Book Path: /home/publib/epubs/book/igypg201.boo

 

[mfcobol2002]

Sorry,
I answered wrong.
Actually the option is already in Net Express.

If you use the directive SET ISO2000 then you can use 31 numeric digits in the PICTURE clause.

If you use the directive SET MF then you can have up to 38 numeric digits in the PICTURE clause.

 

[Lunker]

Jack:
I found it while searching the IBM site.

It was book # SC26-9049-05
book path: /home/publib/os390/bkshelf_390/IGYSH211.BKS

Looks like it might be slightly newer than what you were looking at. It's for Version 2 Release 2

 

[slade]

Thanx, Lunker. I see it now too.

Regards, Jack.

 

[mbkvmk]

Thank you for your help webrabbit. Could you also please provide the code for a signed number ?

Thanks !

 

[webrabbit]

Here is the code for signed DISPLAY:

    01  20-BYTE-WORK-AREA.
        05  WORK-A          PIC 9(14).
        05  WORK-BG.
            10  WORK-B      PIC SV9(6).

    01  WORK-1              PIC S9(14)V9(4).
    01  REDEFINES WORK-1.
        05  WORK-1A         PIC S9(14).
        05  WORK-1B         PIC SV9(4).

    01  WORK-2              PIC S9(12)V9(6).
    01  REDEFINES WORK-2.
        05  WORK-2A         PIC S9(12).
        05  WORK-2B         PIC SV9(6).
    .
    .
    .
        MOVE record-field      TO 20-BYTE-WORK-AREA.
        MOVE WORK-A            TO WORK-1.
        MOVE WORK-BG           TO WORK-2B. 
        *> Use a group move to save sign.
        *> Note that at this point WORK-1A is zero, 
        *> WORK-1 is positive as WORK-A is unsigned, 
        *> and WORK-2A is undefined. 
        MOVE 1                 TO WORK-2A. 
        *> Ensure that WORK-2 is not zero.
        IF WORK-2 IS NEGATIVE
            MULTIPLY -1        BY WORK-1   
            *> Assign correct sign to WORK-1
        END-IF.
        MOVE ZERO              TO WORK-2A. *> Clear to zero.
        do the computations on both WORK-1 and WORK-2.
        ADD WORK-1B            TO WORK-2.
        If WORK-2 IS NEGATIVE
            MULTIPLY -1        BY WORK-2A  
            *> Assign correct sign to WORK-2A
        END-IF.
        ADD WORK-2A            TO WORK-1.
        MOVE WORK-1A           TO WORK-A.  
        *> Note that any sign will be stripped.
        MOVE WORK-2B           TO WORK-BG. 
        *> Use a group move to save sign.
        MOVE 20-BYTE-WORK-AREA TO record-field.

If your compiler supports reference modification, you could use that instead of the group moves.
Keeping track of the proper sign is tricky!

 

[webrabbit]

By the way, I hope all calculations are first order. If there are any roots or powers, all bets are off.

 

[webrabbit]

Found a bug in the earlier code. There would have been a sign in the middle of WORK-2.

Here is the code for signed DISPLAY:

    01  20-BYTE-WORK-AREA.
        05  WORK-A          PIC 9(14).
        05  WORK-BG.
            10  WORK-B      PIC SV9(6).

    01  WORK-1              PIC S9(14)V9(4).
    01  REDEFINES WORK-1.
        05  WORK-1A         PIC S9(14).
        05  WORK-1B         PIC SV9(4).

    01  WORK-2              PIC S9(12)V9(6).
    01  REDEFINES WORK-2.
        05  WORK-2A         PIC S9(12).
        05  WORK-2B         PIC SV9(6).
    01  REDEFINES WORK-2.
        05  WORK-2AU        PIC 9(12).
    .
    .
    .
        MOVE record-field      TO 20-BYTE-WORK-AREA.
        MOVE WORK-A            TO WORK-1.
        *> Note that at this point WORK-1B is zero,
        *> and WORK-1 is positive as WORK-A is unsigned.
        MOVE WORK-BG           TO WORK-2B.
        *> Use a group move to save sign.
        MOVE 1                 TO WORK-2AU.
        *> Ensure that WORK-2 is not zero.
        IF WORK-2 IS NEGATIVE
            MULTIPLY -1        BY WORK-1
            *> Assign correct sign to WORK-1
        END-IF.
        MOVE ZERO              TO WORK-2AU. *> Clear
        do the computations on both WORK-1 and WORK-2.
        ADD WORK-1B            TO WORK-2.
        If WORK-2 IS NEGATIVE
            MULTIPLY -1        BY WORK-2A
            *> Assign correct sign to WORK-2A
        END-IF.
        ADD WORK-2A            TO WORK-1A.
        MOVE WORK-1A           TO WORK-A.
        *> Note that any sign will be stripped.
        MOVE WORK-2B           TO WORK-BG.
        *> Use a group move to save sign.
        MOVE 20-BYTE-WORK-AREA TO record-field.

If your compiler supports reference modification, you could use that instead of the group moves. If WORK-B or WORK-2B are zero, an elementary move will strip the sign. Note that there still could be rounding errors in the 19th and 20th digits.
I hope this one is right. Those signs are tricky.;-)

 

[mbkvmk]

Thank you so much for your help webrabbit !