COMP-? / Extension USAGEs (was: The redefines clause & comp-3

IBM (all platforms and compilers that I know of) have "COMP-3" (as an extens
ion)
= "Packed-Decimal" (USAGE Packed-Decimal was made Standard  in '85 Standard)
.

Many implementors "emulated" this for compatibility with IBM (as they did fo
r
many other IBM extension) in the relatively early days of COBOL.

As Chuck indicates below,  COMP-3 (if supported at all) could be equivalent 
to
BINARY, DISPLAY, or NATIONAL or anything else.

Although I (personally) know of some implementations with other USAGES
equivalent to "Packed-Decimal" - I don't (personally) know of any implementa
tion
that supports COMP-3 where it is NOT Packed-Decimal.  I would be curious if
there are some/any.

Other IBM (extension) usages are NOT as universal.
COMP-1 and COMP-2 are floating point for IBM, but are occasionally other
usages for other compilers
COMP-4 isn't universal even across IBM platforms.  (It is Binary on mainfram
e
and Packed-Decimal on OS/400)

For "workstation" compilers, it is common for COMP-5 to be a "native" binary
(recently adopted by IBM)
More than one vendor has COMP-6 as Packed-Decimal with NO sign-nibble (when 
no
"S" in Picture)

***

Even for USAGE Packed-Decimal and Binary, the Standard doesn't "dictate" exa
ctly
how the data is stored - only what "radix" must be used.

--
Bill Klein
wmklein <at> ix.netcom.com
"Chuck Stevens" <charles.stevens@unisys.com> wrote in message
news:dd8c5m$1n5v$1@si05.rsvl.unisys.com...
>
> "Walter Murray" <wmurray@midtown.net> wrote in message
> news:1123524913_71@spool6-east.superfeed.net...
> 
> that 
>
> Indeed, the very existence of "COMP-3" in the language is dependent on the
> implementor; the '68, '74, '85 and '02 standards are silent on the subject
> of COMP-anything other than just plain COMPUTATIONAL.   It's not just what
> constitutes a "sign nibble" in COMP-3 and how it's interpreted that's
> implementor-defined, it's the very meanings of "nibble" and "COMP-3" in th
e
> first place.
>
>    -Chuck Stevens
>
>

On  8-Aug-2005, "William M. Klein" <wmklein@nospam.netcom.com> wrote:

> Even for USAGE Packed-Decimal and Binary, the Standard doesn't "dictate"
> exactly
> how the data is stored - only what "radix" must be used.

It's amusing that we're supposed to switch from COMP-3 to Packed-Decimal bec
ause
it sounds as though it is more standard that way, even though that is a fict
ion.

USAGE Packed-Decimal yields "portable source code" ('85 Standard or later)

USAGE COMP-3 doesn't even yield portable source code

--
Bill Klein
wmklein <at> ix.netcom.com
"Howard Brazee" <howard@brazee.net> wrote in message
news:dd8g3l$3ge$1@peabody.colorado.edu...
>
> On  8-Aug-2005, "William M. Klein" <wmklein@nospam.netcom.com> wrote:
> 
>
> It's amusing that we're supposed to switch from COMP-3 to Packed-Decimal
> because
> it sounds as though it is more standard that way, even though that is a
> fiction.

To summarise what I could gather:

1) A redefines means that the data file can contain either the
redefined item OR any of the redefining items. This interpretation is
independent of whether the redefines is used on an elementary (which
has a PIC) item or on a group level item.

2) Comp-3 format has a sign in the last nibble on ibm mainframes but
may not appear on others. No standard seems to exist for the same.

Thanks everyone !
Regards,
ed

ed wrote:
> To summarise what I could gather:
>
Not exactly.

> 1) A redefines means that the data file can contain either the
> redefined item OR any of the redefining items. This interpretation is
> independent of whether the redefines is used on an elementary (which
> has a PIC) item or on a group level item.

Of course a REDEFINES area may contain anything, not just what is defined.

>
> 2) Comp-3 format has a sign in the last nibble on ibm mainframes but
> may not appear on others. No standard seems to exist for the same.

COMP-3 will always have a sign somewhere. IBM *IS* the de-facto standard. If
you understand the IBM standard, you can cope with whatever else is out
there.

IBM equipment (and surely others), had/has hardware components that actually
did decimal arithmetic - not just convert a decimal number to binary,
manipulate the bits in binary, and convert the results back to decimal -
actual decimal.

PCs, for example, don't do decimal.

"Howard Brazee" <howard@brazee.net> wrote in message
news:ddabhs$58b$1@peabody.colorado.edu...
>
> On  8-Aug-2005, "William M. Klein" <wmklein@nospam.netcom.com> wrote:
> 
>
> Which means that I can copy a packed-decimal number in a file in one platf
orm
> and it will look the same in another platform?

No, it may or may not (probably will NOT)

>
> Having the word "packed-decimal" compile in two different platforms doesn'
t
> mean
> that it describes the same thing.

Yes, but if you have a "convert to portable file" program that takes "native
"
Packed-Decimal and moves it to "Display Sign is Separate" numeric data (alon
g
with all other "comp-type" data), then that program will be as portable as t
he
sending USAGEs are portable (in source code - not internal format).

"HeyBub" <heybubNOSPAM@gmail.com> wrote in message
news:11fha7rh1o9pe66@news.supernews.com...
> ed wrote:
 
>
> COMP-3 will always have a sign somewhere. IBM *IS* the de-facto standard. 
If
> you understand the IBM standard, you can cope with whatever else is out th
ere.
>

and your evidence for this is what?  I know I asked if COMP-3 means somethin
g
other than Packed-Decimal (as an extension) for any other compiler, but I
certainly would never want to "assume this".  And SEVERAL COBOL compilers *d
o*
support "unsigned" packed-decimal formats.

--
Bill Klein
wmklein <at> ix.netcom.com

William M. Klein wrote:
> "HeyBub" <heybubNOSPAM@gmail.com> wrote in message
> news:11fha7rh1o9pe66@news.supernews.com... 
> 
>
> and your evidence for this is what?

Experience? I understand, therefore I cope.

> I know I asked if COMP-3 means
> something other than Packed-Decimal (as an extension) for any other
> compiler, but I certainly would never want to "assume this".

Whatever works for you is fine by me.

> And
> SEVERAL COBOL compilers *do* support "unsigned" packed-decimal
> formats.

Not really. Even if declared "unsigned," the compiler nevertheless treats
the number as positive. And does the bit representation in these off-brand
compilers you mention differ between an allegedly "unsigned" value and an
honest value differ?

> Not really.

No. Really.

> Even if declared "unsigned," the compiler nevertheless
> treats the number as positive.

The number is treated as positive when unsigned, yes.

> And does the bit representation in these off-brand

What do you mean by 'off-brand' ? Is IBM the the only 'on-brand' ?  Is
a Unisys brand compiler on a Unisys machine 'off-brand' ?

> compilers you mention differ between an allegedly
> "unsigned" value and an honest value differ?

Yes. An unsigned may be implemented as having no nibble for the sign
such that 9(8) occupies 8 nibbles, 4 bytes.

> Experience? I understand, therefore I cope.

You should get out more, you understand less than think you do.

"HeyBub" <heybubNOSPAM@gmail.com> wrote in message
news:11fi7c61ov6rt93@news.supernews.com...
 
>
> Not really.

Yes, really.

> Even if declared "unsigned," the compiler nevertheless treats
> the number as positive.

You're confusing how the data is encoded with how the object code interprets
it.  There is no requirement in the standard that the format of a data item
whose PICTURE character-string does not specify a sign nonetheless must
allocate space for the sign that the programmer has requested not be there.

> And does the bit representation in these off-brand
> compilers you mention differ between an allegedly "unsigned" value and an
> honest value differ?

I think it's highly likely that at least some of your financial transactions
are processed on systems that allocate six (not seven or even eight)
four-bit units, each unit containing a decimal digit, for an item declared
"PICTURE 9(6) PACKED-DECIMAL".   The compiler correctly *understands* such
items as being positive in the *absence* of a sign in both the format and
the data in that format.  Some architectures may require the user to account
for the space occupied by a sign even when the datum in quesion cannot be
negative, but for the life of me I can't imagine why they would continue to
do so.

As to "honest value":  what exactly is dishonest about a representation of a
value that the programmer has expressly stated cannot be negative
nonetheless having the capability of containing a negative value?  Where I
come from, successfully forcing a negative value into an unsigned item
qualifies as data corruption on the part of the programmer!

-Chuck Stevens