Home > Archive > Cobol > August 2005 > COMP-? / Extension USAGEs (was: The redefines clause & comp-3
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
COMP-? / Extension USAGEs (was: The redefines clause & comp-3
|
|
| William M. Klein 2005-08-08, 4:59 pm |
| IBM (all platforms and compilers that I know of) have "COMP-3" (as an extension)
= "Packed-Decimal" (USAGE Packed-Decimal was made Standard in '85 Standard).
Many implementors "emulated" this for compatibility with IBM (as they did for
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 implementation
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 mainframe
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" exactly
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 the
> first place.
>
> -Chuck Stevens
>
>
| |
| Howard Brazee 2005-08-08, 4:59 pm |
|
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 because
it sounds as though it is more standard that way, even though that is a fiction.
| |
| William M. Klein 2005-08-08, 9:59 pm |
| 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
| |
| HeyBub 2005-08-09, 8:59 am |
| 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.
| |
| William M. Klein 2005-08-09, 4:59 pm |
|
"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 platform
> 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 (along
with all other "comp-type" data), then that program will be as portable as the
sending USAGEs are portable (in source code - not internal format).
| |
| William M. Klein 2005-08-09, 4:59 pm |
| "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 there.
>
and your evidence for this is what? 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". And SEVERAL COBOL compilers *do*
support "unsigned" packed-decimal formats.
--
Bill Klein
wmklein <at> ix.netcom.com
| |
| HeyBub 2005-08-09, 4:59 pm |
| 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?
| |
| Richard 2005-08-09, 4:59 pm |
| > 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.
| |
| Chuck Stevens 2005-08-09, 9:59 pm |
|
"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
| |
| epc8@juno.com 2005-08-09, 9:59 pm |
| HeyBub wrote:
> 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.
Two counter examples. First, the IBM-PC XT/370. :-).
A number of micro-computer CPU chips *do* handle addition and
subtraction of (unsigned) packed BCD (2 digits/byte) - the 8080/Z80,
the 65xx and the 80x86 definitely do. Also the 80x87 chip loads and
stores a form of BCD.
I believe that the original 360s handled packed decimal in microcode
not that dissimilar to the operations provided by today's (and
yesterday's) CPU/FPU chips.
I seem to remember that some versions of Rexx and COBOL on the PC take
advantage of these decimal instructions.
[Just for grins look up Wozniak's ingenious method of converting binary
to packed BCD by shifting successive bits into a BCD accumulator that
is being doubled over and over again.]
|
|
|
|
|