Re: [open-cobol-list] displaying max values in comp-5 field

[Bill Klein]

<all previous text snipped>

Some "differences" explained (discussed) about COMP and Binary fields

USAGE COMP
  This is a "standard-defined' USAGE - but what it means is up to the
implementer.  For example, 
for IBM,
  COMP - "big iron" means BINARY
    while
  COMP - on iSeries (S/3x series) is the same as Packed-Decimal
When the compiler is running in "standard conformance mode" TRUNCATION based
on the 9's in the PICTURE clause *must* occur.
 May (most? all?) compilers have a "TRUNC/NOTRUNC" (or something like that)
compiler option/directive.  You need to run with TRUNC "turned on" for
Standard conformance, but often (*NOT* always) NOTRUNC is "better
performing".  IBM mainframe is famous for the fact that when running with
TRUNC(BIN) (equal to most compilers NOTRUNC option), performance is actually
WORSE.  (You need to understand their ODD internals to understand why.  This
has nothing to do with how IBM hardware handles binary processing)

COMP-5
 This was first "officially" introduced in the X/Open Standard - and has
been implemented by many implementors.  To the best of my knowledge, it is
always
 - A binary usage
 - in "machine specific" format (i.e. Big-Endian vs Little-Indian - and I
think there may eve be cases of 1-compliments vs 2-compliments formatting)
 This usage should NOT have truncation based on PICTURE clause

BINARY-short, -long, -char
  were NEWLY introduced in the '02 ANSI/ISO Standards. These usages do not
have (allow) the PICTURE clause so decimal truncation should NEVER happen
with them.  It is relatively common to implement these as variations of
COMP-5 with different picture clauses.  I would, personally, expect little
or no difference (performance OR results) between using BINARY-xxx with
COMP-5 (with the right PICTURE clause).

   * * * * * *

I hope that this note is useful in clarifying both what OC is doing and what
I think it should be doing.