Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Help Please- Large Precision in Cobol Set For AIX Compiler

6 views
Skip to first unread message

ed

unread,
Nov 26, 2003, 2:47:38 PM11/26/03
to
Just a quicky

I am looking at the possiblity of reading a db2 table for a financial app
using cobol, can I go above the PIC S9(19) COMP as I need to handle large
precision numbers (up to 31 digit).

The data would be stored as decimal in db2, i believe there is a compiler
option but cant find it in my documenetation

Any help greatly recieved

Ed


JerryMouse

unread,
Nov 26, 2003, 8:13:23 PM11/26/03
to

Depends on the compiler. In general, yes.

A thirty-one digit number is more than 10 million times the number of
electrons in the universe - just what is it you are measuring?

Oh, wait. I see the Google results for "btinternet + spam" yields over
344,000 hits. Never mind on the question, I think I know the answer.


Harley

unread,
Nov 27, 2003, 7:49:21 AM11/27/03
to

"ed" <ejd...@btinternet.com> wrote in message
news:bq300q$4m0$1...@titan.btinternet.com...

Don't know for sure on your platform.
Check out the ARITH compiler option if you have it.

The Compiler Limits in your manuals might have the information.

William M. Klein

unread,
Dec 3, 2003, 12:39:44 AM12/3/03
to
If you want to use up to 31-digits and are on a "current" IBM compiler using
ARITH (or any - if there were any - implementing the 2002 ISO Standard), make
certain that you read the PERFORMANCE implications of this. For the IBM
compilers there is either "hardware" or "software" support for 31-digits in
COBOL - but even the hardware support requires SIGNIFICANT resources.

Programmer "beware" !!!

--
Bill Klein
wmklein <at> ix.netcom.com
"Harley" <dennis.ha...@worldnet.att.net> wrote in message
news:lpmxb.341861$0v4.18...@bgtnsc04-news.ops.worldnet.att.net...

Judson McClendon

unread,
Dec 3, 2003, 10:16:51 AM12/3/03
to
"William M. Klein" <wmk...@nospam.netcom.com> wrote:
> If you want to use up to 31-digits and are on a "current" IBM compiler using
> ARITH (or any - if there were any - implementing the 2002 ISO Standard), make
> certain that you read the PERFORMANCE implications of this. For the IBM
> compilers there is either "hardware" or "software" support for 31-digits in
> COBOL - but even the hardware support requires SIGNIFICANT resources.

The old IBM 1401, circa late 50's, could do 'unlimited precision'. Fields
were delimited by 'word marks', there were no field lengths in the
instruction format. The Burroughs/Unisys Medium Systems hardware
could handle an integer or floating point mantissa up to 100 digits, and
a multiply could result in a 200 digit product. IOW, it could calculate
(goggle - 1)**2, or the size of the universe in cubic microns, exactly
(well, assuming the size of the universe in cubic microns is an integer,
or a real number with only a few decimal places :-).
--
Judson McClendon ju...@sunvaley0.com (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."


Harley

unread,
Dec 6, 2003, 5:05:18 AM12/6/03
to

"William M. Klein" <wmk...@nospam.netcom.com> wrote in message
news:AGezb.25507$sb4....@newsread2.news.pas.earthlink.net...

| If you want to use up to 31-digits and are on a "current" IBM compiler
using
| ARITH (or any - if there were any - implementing the 2002 ISO Standard),
make
| certain that you read the PERFORMANCE implications of this. For the IBM
| compilers there is either "hardware" or "software" support for 31-digits
in
| COBOL - but even the hardware support requires SIGNIFICANT resources.
|
| Programmer "beware" !!!

I haven't checked yet, but I would assume that the overhead is encountered
only on the fields that require the Extended instructions. (I hope this is
the case, and I'll check next week).

From my experience, the Extended situation comes into play when there are
columns on DB2 tables that exceed the normal limit.
The other option is to return a truncated number from DB2, and hope you
don't drop anything.

0 new messages