Re: J4 - presentation/discussion on "Future of the COBOL Standard"

What the committee intended for both USAGE PACKED-DECIMAL (and USAGE BINARY) is
pretty clear if you look at the implementer defined list (and realize that these
ARE in that list). For Binary it states,

"169) USAGE BINARY clause (computer storage allocation, alignment and
representation of data). This item is required. This item shall be documented in
the implementor's user documentation. (13.16.58, USAGE clause
general rule 4)"

and for Paced-Decimal it states,

"178) USAGE PACKED-DECIMAL clause (computer storage allocation, alignment and
representation of data). This item is required. This item shall be documented in
the implementor's user documentation. (13.16.58, USAGE clause, general rule 10)"

It seems pretty clear to me that for these usages (and many others) that the
"computer storage allocation, alignment and representation of data"

are all implementer defined and intended to be so. There has always been a
difference between implementations whenit comes to packed-decimal and unsigned,
even-number of digit, data items.

On IBM (and IBM-compatible) systems,
Pic 9(02) Packed-Decimal
requires 2 bytes of storage becuase a nibble is used for X"F" to indicate it is
unsigned

Several other systems allow that picture clause to be stored in 1 byte.

It is my belief that the Standard INTENDED to consider both "conforming".

--
Bill Klein
wmklein <at> ix.netcom.com
"Waldek Hebisch" <hebisch@xxxxxxxxxxxxxxxx> wrote in message
news:frr9ru$5so$1@xxxxxxxxxxxxxxxxxxxxx
tim <TimJ@xxxxxxxxxxxx> wrote:
On Sun, 16 Mar 2008 18:41:30 +0000, Waldek Hebisch wrote:

I must admit that I did not see the Cobol standard. But most standards
for programming languages have a chapter about compliance. This chapter
tells you what an implementation ("processor") should do to be
complianat. I have seen _no_ standard that requires using specific
format for data in memory. Closest to such requirement is C standard,
but C standard is pretty clear ("as if" rule) that implementation can do
whatever is conveniet as long as _observable_ effect of running program
agrees with the standard. Of course, there is a question what is
observable. Clearly, rounding has observable effects, but it is easy to
do "decimal" rounding using binary aritmetic.


The COBOL standard is prescriptive about a lot of things in a way that
many other standards are not. I just checked and it is very specific that
the packed decimal data must be stored in radix-10 and each digit must
occupy the minimum amount of storage. Similar prescriptiveness exist about
usage synch and in other areas. Unfortunately cut and paste from the
cobol-85 standard does not work very well or I would include an extract
for you.


Let me play devils advocate: current practice to get "minimum amount of
storage" is to use compression. One very efficient compression method
is arithmetic coding. With reasonable assumptions (that digits are
independent and that all values of a digit have equal probability)
for strings of digits arithmetic coding reduces to using binary encoding.
So, if you stress "minimum amount of storage" you can claim that other
implementations are non-compliant and binary is the only compilant
implementation (on binary machine). Now, one can argue that "each digit"
implies that digits are stored in separate storage units. But this is
clearly not the case in PC implementations: at machine level storage unit
is 8-bit byte (octet) while traditional implementation puts two digits
into a byte. In other words, accesing a digit is composite operation
involving addres aritmetic, shifts and bit masks. Using binary
means that "digit accesor" employs division and remaider operation
-- at concetpual level this does not differ from previous case.

Back to normality: I do not seriously claim that traditional
implementations of packed decimal are non-compliant. What I say is
that one should not read standards too literaly. For example, typical
wording for assignment instruction says that data is stored
(transferred to the storage) -- literal reading would forbid register
allocation. Also, literal reading of standars would exclude
running on modern hardware: hardware executes instructions in
different order than they appear in the program. In both cases
the crucial thing is that differences are not observable:
standards specify abstract machines, real machines are different
but without extra tools (beyond scope of the standard) nobody
can tell the difference.

Another remark: IBM is pushing "decimal floating point". My
understanding of their announcements is that thay want to switch
decimal arithmetic in Cobol and PL/I to use "decimal floating point".
However, "decimal floating point" stores three-digit groups
ech in 10 bits. Your interpretation of the fragment above
seem to be that representing packed decimal as "decimal floating
point" is non-compilant (IMHO the only sticky point is
"minimum amount of storage" -- "decimal floating point" stores
exponent, which for fixed point types is redundant).

So, I still belive that the intent of the Cobol standard is to
give you an abstract model and that implementation is compliant
as long as observable aspects agree with the model. So really,
the question is what is intended to be observable. Some folks
here in the past claimed to use packed decimal to be able to
easily read numbers in hexadecimal core dump. I would say that
core dumps are outside scope of the Cobol standard, so can
be ignored. More problematic may be interface to C/assembler
-- I am not sure how much Cobol standard says here, but I would
say that each Cobol compiler have enough possibilites to choose
data representation which is incompatible with other compileres
to make C/assembler interface compiler specific. Another area
are files: files are frequently used to exchange data between
systems, so it makes sense to use "portable" represention for
items in the files. But IIUC represention on disk may be
different from representation in memory.

Now, literally following standard may be the easiest way to
get compliant implementation -- abstract interpretation means
that you need to understand the whole standard in order to
determine observable consequences. And when standard is revised
it may introduce changes which invalidate an implementation
which used some freedoms given by previous standard.

It would be interesting to get comment from Bill Klein what
the committee really intended concerning packed decimal.

There are also a lot of rules about situations where errors or warnings
must be detected. For example in data definitions, clauses must be in a
certain order and warnings given about exceptions.


Well, that completly different story: errors or warnings are clearly
observable. OTOH it makes sense to have flags which turn on
nonstandard behaviour, where you detect less or more errors.

--
Waldek Hebisch
hebisch@xxxxxxxxxxxxxxxx


.

Relevant Pages

  • Re: J4 - presentation/discussion on "Future of the COBOL Standard"
    ... I have seen _no_ standard that requires using specific ... the packed decimal data must be stored in radix-10 and each digit must ... occupy the minimum amount of storage. ... give you an abstract model and that implementation is compliant ...
    (comp.lang.cobol)
  • Re: storage for temporaries
    ... > Which means that this "temporary storage" doesn't have to last beyond the ... >> What does the Standard say about ... So the value of the pointer you pass is indeterminate ... I agree (if at all we can talk about an rvalue object - see below). ...
    (comp.lang.c)
  • Re: I love yuwie
    ... However, in an English usage newsgroup that I read, someone recently ... The Columbia Guide to Standard American ... Others point out that bad is a flat adverb and that therefore the -ly ... is a satisfactory explanation for this pattern of Standard divided ...
    (alt.marketing.online.ebay)
  • Re: HID pointing device and the Virtual Desktop
    ... I am using a standard Mouse USAGE with absolute values for X and Y for this ... Digitizers USAGE. ... >pointing device should map across the whole virtual desktop: ... > standard absolute pointing device report descriptor, ...
    (microsoft.public.development.device.drivers)
  • Re: Equivalence of derived types with default initializers?
    ... The relevant text seems to be at the end of 14.6.3.3 in the F95 standard: ... "Default initialization may be specified for a storage unit that is ... assures that I, R1, and R2 are totally associated. ...
    (comp.lang.fortran)