Re: Survey - "Most compilers" and USAGE COMP (was: Moving display to comput

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:L1ZXe.127169$vo5.13829@fe01.news.easynews.com...
> "Chuck Stevens" <charles.stevens@unisys.com> wrote in message
> news:dgpid8$2qdt$1@si05.rsvl.unisys.com... 
> <snip> 
have 
>
> OK, Chuck, I'll ask ...
>
> Please reply with the following information - include compiler (release of
> version if appropriate) and Operating System.  I'll start this out with
what I
> know (feel free to correct me, if you think I am in error on any of this):
>
> 1) Do you treat "COMP" as a BINARY format?
>  - IBM mainframe (all releases, current and past) - YES
>  - IBM Workstation (PC, Windows, AIX) - Yes
>  - Micro Focus (all platforms, all releases) YES (unless MAKESYN or
something
> similar is used)
>  - Fujitsu - Yes
>  - CA-Realia - Yes
>  - AcuCOBOL - Yes (I believe)
>  - RM - Yes (but I don't think they ALWAYS have)
>  - KOBOL - Yes
>  - OpenCOBOL and TinyCOBOL - Yes (I believe)
>
>            ***
>  - IBM OS/400 (S/3x follow-ons) - No (treated as Packed-Decimal)

Unisys MCP COBOL(68), no longer supported:  Yes, 39-bit integer in a 48-bit
word.
Unisys CCOBOL74 and COBOL85:  No.

The original point wasn't necessarily about "a BINARY format" but went
rather further to indicate that "Most compilers treat both 9(2) COMP and
9(4) COMP as 2-byte binary fields".    We don't, and even if we did treat
COMP as "a BINARY format" there's no guarantee that that has anything to do
with how many bits we allocate for it.

> 2) If you treat COMP as a BINARY format, does it have a (non-Standard)
option
> for "no truncation to PICTURE"
>   - IBM mainframe - Yes (via compiler option, also supports COMP-5 in
recent
> releases)
>   - IBM workstation - Yes (via compiler option, also supports COMP-5)
>   - Micro Focus - Yes (via compiler directive, but also supports COMP-5)
>   -  Fujitsu - Yes (via compiler directive, but also supports COMP-5)
>  - CA-Realia - Yes (via compiler option)

For COBOL(68), no; the magnitude maximum for PIC 9 through PIC 9(11) was
2**39, and that for PIC 9(12) through PIC 9(23) was 2**78.

[Note that we have options for USAGE BINARY in both COBOL74 and COBOL85
whereby truncation may be specified explicitly or disabled explicitly (by
default it's disabled in '74, enabled in '85).]

> 3) If you treat COMP as Binary format, "big-endian" or "little-endian"
>  - IBM mainframe - always big-endian
>  - IBM Workstation - changeable by compiler option (I think)
>  - Micro Focus - depends on platform (but usually changeable by compiler
> directive)

N/A.   Big-endian for BINARY and for COBOL(68) COMP.

> 4) If you treat COMP as Binary format, do you allocate 1 byte, 2-byte, or
other
> for PIC S9(01)
>  - IBM (all platforms) - 2 bytes
>  - Micro Focus - subject to compiler directive (IBMCOMP)

COBOL(68) allocated 48 bits (6 bytes) for PIC 9 through PIC S9(11), twelve
for anything larger, up to PIC S9(23) (the maximum) allowed.

> 5) If you have a "packed-decimal" format do you allocate "nibble" (in
storage)
> for sign - even if no SIGN in Picture?
>  - IBM mainframe - always
>  - IBM workstation - always
>  - IBM OS/400 - always
>  - Micro Focus - yes for COMP-3 and Packed-Decimal; no for COMP-6

Unisys MCP COBOL(68), COBOL74 and COBOL85, and COBOL compilers on Burroughs
Small and Medium Systems and their successors have never allocated space for
a sign on a packed-decimal format unless the programmer requested it.

> 6) If a SIGN (with no separate clause) is specified, for DISPLAY items,
can you
> tell difference between "NO SIGN" and "POSITIVE" sign?
>  - IBM (all platforms) - Yes (unless ASCII specially requested for
Workstation)
>  - Micro Focus - dependent upon EBCDIC or ASCII character set or sign
directives
> specified
>  - Fujitsu - No (may have a directive for "EBCDIC" sign emulation)

Presuming the data item is otherwise correctly formed, no; @C@ and @F@ in
the sign field are both treated as positive, and @D@ as negative, in a
numeric test.  Anything else in the sign field will cause a false result on
numeric, as will anything other than @F@ in the zones of the numeric portion
and anything other than decimal values in the digits.  Note that *on
retrieval*: if the sign position contains @D@ the value is treated as
negative, otherwise as positive;  zones through the rest of the item are
ignored; and nondecimal digits these days are interpreted as 9's.

That our implementations allow @F@ in the zone sign position of a signed
numeric display item is for compatibility with earlier systems and, I
believe, with IBM mainframes.  Note also that the standards provide for
this; the '74 and '85 standards state "the implementor defines what
constitutes valid sign(s) for data items not described with the SIGN IS
SEPARATE clause".  The wording is different, but the effect is the same, in
the 2002 standard.

-Chuck Stevens