Frank Swarbrick
2015-09-23 17:46:54 UTC
COMPUTATIONAL-5 was added to COBOL as an IBM extension in order to allow binary numeric fields to behave as "native binary" fields; that is they "can contain
values up to the capacity of the native binary representation (2,
4, or 8 bytes), rather than being limited to the value implied by
the number of nines in the picture for the item (as is the case for
USAGE BINARY data)."
This is all well and good except (in my opinion) for three things:
- It's an IBM extension, not "standard COBOL".
- the minimum size is two bytes, not one. PIC S9(1) COMP-5 takes up two bytes.
- The following surprising (to me) behavior when ON SIZE ERROR is specified: "USAGE
NOTE: When the ON SIZE ERROR phrase is used on an arithmetic statement
and a receiver is defined with USAGE COMP-5, the maximum value that
the receiver can contain is the value implied by the item's decimal
PICTURE character-string. Any attempt to store a value larger than
this maximum will result in a size error condition."
Let's say 'n' is defined as USAGE COMP-5 PICTURE 9(4) and it is set to a value of 9999.
ADD 1 TO n
This results in n being set to 10000.
ADD 1 TO n
ON SIZE ERROR
DISPLAY 'size error condition occurred'
END-ADD
This results in the size error conditional block being executed and the value of n being unchanged (remaining 9999).
Since the COBOL 2002 standard COBOL has supported true "native binary" data items with the following USAGE clauses where the minimum ranges are:
- BINARY-CHAR SIGNED -128 [-2**7] < n < 128 [2**7]
- BINARY-CHAR UNSIGNED 0 ≤ n < 256 [2**8]
- BINARY-SHORT SIGNED -32768 [-2**15] < n < 32768 [2**15]
- BINARY-SHORT UNSIGNED 0 ≤ n < 65536 [2**16]
- BINARY-LONG SIGNED -2147483648 [-2**31] < n < 2147483648 [2**31]
- BINARY-LONG UNSIGNED 0 ≤ n < 4294967296 [2**32]
- BINARY-DOUBLE SIGNED -2**63 < n < 2**63
- BINARY-DOUBLE UNSIGNED 0 ≤ n < 2**64
No PICTURE clause is used (or even allowed) for these usages. Their size and numeric ranges are based solely upon the USAGE clause.
ISO/IEC 1989:2014(E) [The COBOL 2014 standard] also has this to say:
"14.7.4 SIZE ERROR phrase and size error condition
[...]
The size error condition exists in the following cases:
[...]
3) if, after radix point alignment and any applicable rounding specifications, the result of an arithmetic statement
is further from zero than permitted for the associated resultant data item;"
This means that if n (as above) was defined as USAGE BINARY-SHORT UNSIGNED then in both of the earlier add statements no "size error" condition would occur and n would be set to 10000.
All of this is a very long prelude to the question, how important is it for Enterprise COBOL to support these "new" native binary usage types?
I personally would much prefer "USAGE BINARY-SHORT UNSIGNED" to "USAGE COMP-5 PICTURE 9(4)" to represent an unsigned halfword binary field. And I think it would make it more obvious what the range and size of these fields are, and when they should be used (such as interfacing with CICS, C/C++, etc.); plus the "size error" behavior would be more, um, reasonable. But are these enough to push IBM to make this a priority? I don't know...
Thoughts?
Frank
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
values up to the capacity of the native binary representation (2,
4, or 8 bytes), rather than being limited to the value implied by
the number of nines in the picture for the item (as is the case for
USAGE BINARY data)."
This is all well and good except (in my opinion) for three things:
- It's an IBM extension, not "standard COBOL".
- the minimum size is two bytes, not one. PIC S9(1) COMP-5 takes up two bytes.
- The following surprising (to me) behavior when ON SIZE ERROR is specified: "USAGE
NOTE: When the ON SIZE ERROR phrase is used on an arithmetic statement
and a receiver is defined with USAGE COMP-5, the maximum value that
the receiver can contain is the value implied by the item's decimal
PICTURE character-string. Any attempt to store a value larger than
this maximum will result in a size error condition."
Let's say 'n' is defined as USAGE COMP-5 PICTURE 9(4) and it is set to a value of 9999.
ADD 1 TO n
This results in n being set to 10000.
ADD 1 TO n
ON SIZE ERROR
DISPLAY 'size error condition occurred'
END-ADD
This results in the size error conditional block being executed and the value of n being unchanged (remaining 9999).
Since the COBOL 2002 standard COBOL has supported true "native binary" data items with the following USAGE clauses where the minimum ranges are:
- BINARY-CHAR SIGNED -128 [-2**7] < n < 128 [2**7]
- BINARY-CHAR UNSIGNED 0 ≤ n < 256 [2**8]
- BINARY-SHORT SIGNED -32768 [-2**15] < n < 32768 [2**15]
- BINARY-SHORT UNSIGNED 0 ≤ n < 65536 [2**16]
- BINARY-LONG SIGNED -2147483648 [-2**31] < n < 2147483648 [2**31]
- BINARY-LONG UNSIGNED 0 ≤ n < 4294967296 [2**32]
- BINARY-DOUBLE SIGNED -2**63 < n < 2**63
- BINARY-DOUBLE UNSIGNED 0 ≤ n < 2**64
No PICTURE clause is used (or even allowed) for these usages. Their size and numeric ranges are based solely upon the USAGE clause.
ISO/IEC 1989:2014(E) [The COBOL 2014 standard] also has this to say:
"14.7.4 SIZE ERROR phrase and size error condition
[...]
The size error condition exists in the following cases:
[...]
3) if, after radix point alignment and any applicable rounding specifications, the result of an arithmetic statement
is further from zero than permitted for the associated resultant data item;"
This means that if n (as above) was defined as USAGE BINARY-SHORT UNSIGNED then in both of the earlier add statements no "size error" condition would occur and n would be set to 10000.
All of this is a very long prelude to the question, how important is it for Enterprise COBOL to support these "new" native binary usage types?
I personally would much prefer "USAGE BINARY-SHORT UNSIGNED" to "USAGE COMP-5 PICTURE 9(4)" to represent an unsigned halfword binary field. And I think it would make it more obvious what the range and size of these fields are, and when they should be used (such as interfacing with CICS, C/C++, etc.); plus the "size error" behavior would be more, um, reasonable. But are these enough to push IBM to make this a priority? I don't know...
Thoughts?
Frank
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN