## 24 digit number: Arithmetic operations?

85 pts.
Tags:
COBOL/400
IBM i
RPG
Hi, I need to work with numbers which are digits long. Why? Because this is the way to create a German IBAN code from Bank Code and Bank account: Concatenate Bank Code (8 digits) plus Account nbr (10 digits, leading zeroes) plus "131400" to a 24 digit number. Compute Modulo 97 of this number. (or divide it by 97 into a integer, multiply by 97, and get the difference). Does anyone know any programming language or other way to do this on a IBMi?

Thanks. We'll let you know when a new response is added.

What’s the problem? RPG has been able to handle 31 digit numbers for decades. 63 digit numeric constants.

Add to that the %rem() and %mod() BIF’s.

## Discuss This Question: 8 Replies

Thanks. We'll let you know when a new response is added.
• What is the problem? RPG and COBOL would both be fine with it. -- Tom
report
• Are you having a problem with this? It only takes two simple RPG statements for the mod(97) result. The part that might be less clear could be the RPG D-specs that make the construction of the 24-digit number from all of the digits easy. -- Tom
report
• One problem is the length of the number. 24 digit integer is out of limitations of Cobol, Java etc. The solution is to cut the number into pieces: 9 digits, 7 digits, 7 digits 1 digit. Calculate the modulo of part one, concatenate it with part 2, modulo again and so on. The algorithm is well known. The calculation itself is about simple 10 lines ob Cobol code. I just wrote a simple Cobol program for AS/400 doing this: CALL PGM(IBANLIB/IBANCALC) PARM('54092400' '123456' '') parm 1 = bank code, parm 2 = account, parm 3 = outparm IBAN. In addition to the modulo calculation you need some simple code for the specialties of some banks. The final documentation is available from Bundesbank since April 03. Also I would add the usual SQL lines, so that Cobol programs can be called from programs/CLs inside the AS/400, as well as from outside as a service, like from Java programs like this: ProgramCall instanceProgramCall = new ProgramCall(instanceAS400Session, "/QSYS.LIB/IBANLIB.LIB/IBANCALC.PGM", as400parm); Maybe I will publish the code on some freeware download platform, or sell it for a sixpack beer.
report
• It would only be a problem if you are using an old obsolete AS/400; and if that's the case, no one can help because you didn't tell us critical information. Even in V5R3 (which is also so old that it's been out of support for four years), COBOL can handle 24-digit numbers and larger.
.
Here is debug output from a COBOL program on V5R3 that shows the value of a 24-digit number:
``` Debug . . .
.
F12=Resume       F17=Watch variable   F18=Work with
BIG-NBR = 000000000000000000000052.```
I don't know why you're having trouble. You need to tell us about your environment because it has worked with larger than 24 digits for a number of years.
.
Tom
report
• As a side note, REXX has handled numbers of essentially any scale (up to the general 16MB limit) from essentially the beginning. -- Tom
report
• Maybe you should try to find out the difference between maximum size and maximum precision.
report
• Yes, that should have been "precision AND scale". Typos happen, and this editor doesn't help. To demonstrate further, I changed my test COBOL function to issue a COMPUTE against a S9(25)v9(25) decimal variable. The debug EVAL of the variable now shows:
```Debug . . .
.
F3=End program   F6=Add/Clear breakpoint   F10=Step   F11=Display variable
F12=Resume       F17=Watch variable   F18=Work with watch   F24=More keys
BIG-NBR = 0000000000000000000000052.0000000000000000000000000```
If it's still not big enough, I can make both precision AND scale have more digits. And that's still V5R3. I still haven't heard why you are having a problem. This function of mine is just a small test program that I had available. I modified it to shove a big number into it to show it could be done.
.
This is the entire program:
```       PROCESS APOST NOPRTCORR
DATE
TIME
TIMESTAMP
CVTTODATE
VARCHAR
Identification Division.
Program-ID.      TST2    .
.
Environment Division.

Configuration Section.
Source-computer.    IBM-AS400.
Object-computer.    IBM-AS400.
.
Data Division.
File Section.
.
Working-storage Section.
.
EXEC SQL
INCLUDE SQLCA
END-EXEC.
.
77  big-nbr                 pic s9(25)v9(25) comp-3.
.
01  HOST-VARS.
05 iCnt                 pic s9(18) binary.
05 iTot                 pic s9(5) comp.
05 minFile              pic x(10).
05 maxFile              pic x(10).
.
Procedure Division.
.
00-Main-driver.
.
EXEC SQL
SELECT COUNT(*), SUM(APNKYF), MIN(APFILE), MAX(APFILE)
INTO :HOST-VARS
FROM ACCPTH
END-EXEC.
.
compute big-nbr = iCnt
.
goback.
.
00-Main-driver-exit.  exit.```
I know it has embedded SQL, but that has no effect on the COBOL. If you wish, you can create file ACCPTH by running DSPFD TYPE(*ACCPTH) to an *OUTFILE.
.
It still isn't clear where you are having a problem. Numbers this big just aren't an issue for any recent COBOL. An older AS/400 might have trouble, but no IBM i release would.
.
Tom
report
• I use a data structure to work with big numbers:

d                 DS
d  reken_alfa               1     24A
d  reken_num              1     24  0

If you move a numeric value to REKEN_ALFA, you can use REKEN_NUM in a calculation:

eval      reken_alfa = '123456789012345678901234'

if        %rem(reken_num : 97)   <> 1    etcetera