View previous topic :: View next topic |
Author |
Message |
ashutosh_agl3 Beginner
Joined: 14 Aug 2003 Posts: 28 Topics: 15
|
Posted: Wed Feb 18, 2004 10:31 am Post subject: How to do arithmatic operation in COBOl for long integers |
|
|
Is there anyway by which we can do arithmatic operation on long integers (having more than 18 digits) |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
kolusu Site Admin
![Site Admin Site Admin](images/ranks/adminpic.jpg)
Joined: 26 Nov 2002 Posts: 12369 Topics: 75 Location: San Jose
|
Posted: Wed Feb 18, 2004 10:59 am Post subject: |
|
|
ashutosh_agl3,
With the new Enterprise COBOL for z/OS and OS/390 V3R2 you can code up to 31 digits in the picture clause. But you will need the compiler option ARITH(EXTEND) to perform arthimetic operations on long integers
You can code up to 18 digits in the PICTURE clause when you compile using the default compiler option ARITH(COMPAT) (referred to as compatibility mode). When you compile using ARITH(EXTEND) (referred to as extended mode), you can code up to 31 digits in the PICTURE clause.
Check this link for detailed explanation of ARITH compiler option
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3PG10/2.4.5?DT=20020923143836
Hope this helps...
Cheers
Kolusu _________________ Kolusu
www.linkedin.com/in/kolusu |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
ashutosh_agl3 Beginner
Joined: 14 Aug 2003 Posts: 28 Topics: 15
|
Posted: Thu Feb 19, 2004 11:06 am Post subject: |
|
|
WILL THERE BE ANY OTHER ISSUES WHILE COMPUTATION....
I AM FACING SOME PROBLEM IN REPRESENTATION OF THE 30 DIGIT NUMBER....
THE NUMBER WHEN IN a X(30) , alphanumeric variables has corect numeric value but when moved to a numeric variable of type 9(30) has some misrepresentation....
what can be possible reason for this? |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
kolusu Site Admin
![Site Admin Site Admin](images/ranks/adminpic.jpg)
Joined: 26 Nov 2002 Posts: 12369 Topics: 75 Location: San Jose
|
Posted: Thu Feb 19, 2004 11:10 am Post subject: |
|
|
ashutosh_agl3,
You will have wrong results if the x(30) field has spaces in it. You need to use an INSPECT statement to remove the space and move it to 9(30) field.
Show the code and contents of X(30) & 9(30) fields
Kolusu _________________ Kolusu
www.linkedin.com/in/kolusu |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
ashutosh_agl3 Beginner
Joined: 14 Aug 2003 Posts: 28 Topics: 15
|
Posted: Thu Feb 19, 2004 11:18 am Post subject: |
|
|
no the X(30) contains all 30 digits exmple:
651310406401912040024657817701
but when moved to 9(30) it is not moved properly
the code which does this is actually a part of 30 digit random number generation ..... which makes use of time stamp and other numeric calculation so that there always will be 30 digit number only in X(30)
when moved to9(30) fro above example the number is moved as
6513104064019120400246578
and followed by some garbage
Please suggest some reason for the same..
Thanks |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
kolusu Site Admin
![Site Admin Site Admin](images/ranks/adminpic.jpg)
Joined: 26 Nov 2002 Posts: 12369 Topics: 75 Location: San Jose
|
Posted: Thu Feb 19, 2004 1:22 pm Post subject: |
|
|
ashutosh_agl3,
Here is a sample pgm which does not have any problem moving the data.
Code: |
CBL ARITH(EXTEND)
IDENTIFICATION DIVISION.
PROGRAM-ID. SAMPLE
DATE-COMPILED.
ENVIRONMENT DIVISION.
DATA DIVISION.
FILE SECTION.
WORKING-STORAGE SECTION.
01 WS-CHAR PIC X(30).
01 WS-NUM PIC 9(30).
PROCEDURE DIVISION.
MOVE '651310406401912040024657817701' TO WS-CHAR
MOVE WS-CHAR TO WS-NUM
DISPLAY 'THE CHAR VALUE: ' WS-CHAR
DISPLAY 'THE NUM VALUE: ' WS-NUM
GOBACK.
|
The output from that job is:
Code: |
THE CHAR VALUE: 651310406401912040024657817701
THE NUM VALUE: 651310406401912040024657817701
|
My compiler options are:
Code: |
PP 5655-G53 IBM Enterprise COBOL for z/OS and OS/390 3.2.0
PROCESS(CBL) statements:
CBL ARITH(EXTEND)
Options in effect:
NOADATA
NOADV
APOST
ARITH(EXTEND)
AWO
BUFSIZE(31744)
NOCICS
CODEPAGE(1140)
NOCOMPILE(S)
NOCURRENCY
DATA(31)
NODATEPROC
NODBCS
NODECK
NODIAGTRUNC
NODLL
NODUMP
NODYNAM
NOEXIT
NOEXPORTALL
FASTSRT
FLAG(I,I)
NOFLAGSTD
INTDATE(ANSI)
LANGUAGE(EN)
LIB
LINECOUNT(60)
NOLIST
MAP
NONAME
NSYMBOL(DBCS)
NONUMBER
NUMPROC(NOPFD)
OBJECT
NOOFFSET
OPTIMIZE(STD)
OUTDD(SYSOUT)
PGMNAME(COMPAT)
RENT
RMODE(AUTO)
SEQUENCE
SIZE(MAX)
SOURCE
SPACE(1)
NOSQL
NOSSRANGE
NOTERM
NOTEST
NOTHREAD
TRUNC(OPT)
NOVBREF
NOWORD
XREF(FULL)
YEARWINDOW(1900)
|
Hope this helps...
Cheers
kolusu _________________ Kolusu
www.linkedin.com/in/kolusu |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
Glenn Beginner
Joined: 23 Mar 2003 Posts: 56 Topics: 3
|
Posted: Thu Mar 04, 2004 12:14 am Post subject: |
|
|
Odds are the original poster may not have this capability, especially given what the person has posted. I'm not sure if 9(30) is valid for their compiler, but for computational purposes it seems like it's only handling 18 digits, but passing 30 bytes around....
The traditional solution for mathematics like this has always been to code arithmetic operations off the X(30). Like as an example for addition, you group the X(30) into comfortable sections and then add each section and carry it. Basically code the pencil and paper arithmetic. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
|
|