Re: [open-cobol-list] OpenCOBOL release 1.0

[Alain]

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>