[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [open-cobol-list] OpenCOBOL release 1.0
From: |
Alain |
Subject: |
Re: [open-cobol-list] OpenCOBOL release 1.0 |
Date: |
Sun, 30 Dec 2007 19:27:06 +0100 |
On Sat, 29 Dec 2007 15:13:35 -0600
"Bill Klein" <address@hidden> wrote:
> I can't speak for what the internals are for OC, but I can (hopefully) make
> it clear that there is a "world of difference" between C INT (base 2 based)
> items and COBOL PIC 9(x) items.
>
> It is entirely possible that you are looking for one of the "old" extension
> data types, such as COMP-5 which in many (not all) COBOL compilers uses the
> PIC to determine how much storage is allowed - but "truncates" based on
> binary values.
>
> In Standard COBOL - until the 2002 Standard, when you used PIC 9(x)
> truncation MUST be done at base-10 limits. (Before COMP-5, many vendors had
> a "TRUNC" compiler option/directive to allow truncation of binary data items
> at base-2 values but these were always documented as NON-standard).
>
> There isn't even any requirement that COMP be a binary data type. (For
> example, on IBM OS/400 compilers it is now and always has been
> packed-decimal).
>
> USAGE BINARY must be a "binary" data type - but storage (little-/big-endian)
> and even whether 0 or 1 complements are used and NOT standard across
> implementations (and operating systems)
>
> When it comes to the '02 Standard, there ARE new data types (e.g.
> BINARY-CHAR, BINARY-LONG, etc) which do NOT have any picture clause and
> which are "defined" in terms of what binary values they can hold.
>
> Bottom-Line:
> If OC is like "most" COBOL compilers when you define
> Pic S9(9) COMP
> it is "guaranteed" that all values that will fit in this field can ALSO fit
> into an INT32 (C-type) field. The reverse is NOT true, i.e not all INT32
> values will fit into this field.
>
> If you want a COBOL field that is guaranteed to hold all values from an
> INT32 field, then you need
> PIC S9(10) COMP
> but that will take MORE STORAGE than the corresponding INT field will.
>
> "storage" requirements for base-2 and base-10 data items simply do not
> "match". If you have a field big enough to hold one, then it won't other
> the other's largest value or vice versa.
>
>
> > -----Original Message-----
> > From: address@hidden
> > [mailto:address@hidden On
> > Behalf Of Alain
> > Sent: Saturday, December 29, 2007 1:20 PM
> > To: address@hidden
> > Cc: Rildo Pragana; address@hidden
> > Subject: Re: [open-cobol-list] OpenCOBOL release 1.0
> >
> > On Sat, 29 Dec 2007 14:42:10 +1100
> > Tim Josling <address@hidden> wrote:
> >
> > > On Fri, 2007-12-28 at 11:27 +0100, Alain wrote:
> >
> > >
> > > -2 147 483 648 and +2 147 483 647 are not the largest possible
> > > magnitide 10-digit numbers.
> > >
> > > 9,999,999,999 and -9,999,999,999 are 10 digit numbers which
> > fit in pic
> > > s9(10) but not in a 32-bit int.
> > >
> > > So s9(10) comp *is* too big for int32. Though not all
> > values you might
> > > put there are necessarily too big.
> > >
> > > Tim Josling
> > >
> > Hello Tim,
> >
> > Happy to have news from you.
> >
> > I well know what you write but seem to me that PIC S9(9) COMP
> > is not enough
> > large for RECEIVE the "int" SEND by libpq : PGconn, PQntuple,
> > and so on ...
> > This worked well with O-C-0.23.19 and Postgres-7.x with
> > fields defined as
> > PIC S9(8) COMP but don't work with O-C-1.0 (old) and Postgres-8.x.
> > I have write about to Rildo Pragana, but he answer that all
> > interfaces don't
> > work again with PG-8.x and must be rewrited ...
> > In fact, this works for some fields and not for other.
> > As I have read in cobol specifications (from ANSI ?) that you
> > know better
> > than me and I cannot retrieve from internet, that a cobol PIC
> > s9(9) cannot
> > have a value more than 999,999,999 not enough for
> > 2,147,483,647 I have tried
> > with S9(10) COMP and, now, I am trying with PIC S9(9) COMP-5,
> > but not with
> > too much hope that can work well ...
> > After I was trying on an old version of Linux with
> > O-C-0.23.19 + Postgres-7.4,
> > and after O-C-1.0 (new) and if this works, on a new version
> > of Linux with
> > O-C-1.0 and Postgres-8.2 ... with the time perhaps I
> > understand what is not
> > working. Unfortunally I'm not good enough in C for rewrite
> > the interface for
> > cobol to postgres.
> >
> > Well, what is the state of Cobol for GCC ?
> >
> > Best regards,
Hi Bill,
I'm a very (too ?) old cobol programmer, knowledging a little C and some others
langages, so I well know that I can't put more than 2,147,483,647 on a pic
"s9(10) comp" for call a C subroutine using an "int" for receive the field, but
it seem to me, also, that "PIC S9(9) COMP" is not large enough.
Ok, this seem resolved using "PIC S9(9) COMP-5" with help of Sergey.
But was working with O-C-0.23-x don't work with O-C-0.33 ...
I have nothing to do with MF or IBM or Burroughs or other FLAVOURS,
I just hope O-C-1.0 CAN compil well progs working with O-C-0.23.x
and I can work a little with sed for modify my about 1,000 progs working with
O-C-0.23 from some years, what I'm doing now ...
but without an advertising "what difference between old versions" that is not
easy. Perhaps Roger can add a flavour "old-OC" ???
That is not your problem, but
You are a very good fellow if you can send me the internet address of ANSI
cobol specifications I have it some time ago but lost.
Regards,
--
Alain <address@hidden>
Message not available
Re: [open-cobol-list] OpenCOBOL release 1.0, Ben Duncan, 2007/12/29