COBOL Files and COBOL Data types.
Stephen J Spiro
COBOL is, far and away, the most versatile high level language in the
computer industry. From the beginning, COBOL was designed to be
flexible in handling all manner of file structures and data
structures.
Data types and file organization is determined by vendors to operate
on particular hardware and operating system architectures. COBOL is
designed to process these formats.
HIDAM databases (such as IMS) came with their own Application
Programming Interfaces (APIs), so "native" COBOL syntax was never
developed. Relational databases came with SQL from the beginning, so
"native" COBOL syntax was never developed. The CODASYL Journal of
Development had some syntax for new datatypes, but it has not been
adopted because a commercial need has never developed.
COBOL syntax handles sequential, relative, and indexed files natively.
"Line Sequential" should have been added to the standard, but all
COBOL compilers which run on systems which use it, have it as an
extension.
There was a great deal of effort to expand the new COBOL standard to
handle many more datatypes than previously. Incomprehensibly, 3 data
types were omitted, and they must be processed in COBOL using kludges:
(SQL types VARCHAR and VARCHAR-LONG, as well as field-mark deleimited
data types). Nevertheless, COBOL remains the most flexible high-level
language in the industry.
A note: the format of PACKED-DECIMAL is not specified in the COBOL
standard. Its internal representation varies from computer-maker to
computer-maker. Not only is the internal representation different,
the Syntax is not standard, either. Some call it COMP-3, others
COMP-2 or anything else. ALL COMP-x data types are
IMPLEMENTOR-DEFINED. They are ALL extensions to the standard.
Programmers using state-of-the-art whiz-bang computer-science
leading-edge languages frequently need to access files and/or data
types originally created by COBOL programs, and find that their
state-of-the-art whiz-bang computer-science leading-edge languages are
totally inadequate to handle anything except some subset of their
systems capabilities. ERRONEOUSLY, they blame this on COBOL, rather
than the inadequate state-of-the-art whiz-bang computer-science
leading-edge tools which they are using.
Stephen J Spiro
Member, J4 COBOL Standards Committee
William M. Klein
--
Bill Klein
wmklein <at> ix.netcom.com
"Stephen J Spiro" <stephe...@mail.com> wrote in message
news:928495c6.02011...@posting.google.com...
> There are no such things as COBOL files and COBOL data types.
>
This is at best MISLEADING. As Stephen states below, COBOL *does* define
certain file types, i.e. sequential, relative, and indexed. The implementor
of the COBOL "system" *must* provide support for these types and the 'way'
they work MUST be as defined in the Standard. It is true that the "internal
structure" is NOT defined in the Standard, but certain "things" must be
provided by the COBOL vendor - if the "operating system" does not provide
them for the language. Compare, for example, the introduction of the SIMVRD
IBM compiler option which provided "variable lange relative file support" -
even when the operating system (IBM file system) did NOT provide such a
capability.
<snip>
>
> A note: the format of PACKED-DECIMAL is not specified in the COBOL
> standard. Its internal representation varies from computer-maker to
> computer-maker. Not only is the internal representation different,
> the Syntax is not standard, either. Some call it COMP-3, others
> COMP-2 or anything else. <snip>
All COBOL compilers that support the '85 Standard *must* provide support for
USAGE PACKED-DECIMAL. It is true that earlier Standards did not include
this definition, and that, therefore, many vendors provide ALTERNATIVE
syntax for packed-decimal data types. However, if you use USAGE
Packed-Decimal syntax, you are GUARANTEED of source-code portability across
'85 Standard (and later) compilers. Again, it is true that what this MEANS
for each COBOL vendor may vary. The classic example is "unsigned -
even-number of digit - Packed-Decimal items". If you have a data item
defined as:
05 PD-1 Pic 9(4) Packed-Decimal.
Some vendors "provide" a sign-nibble, thereby forcing this item to take 3
bytes of storage - while other vendors do NOT require the sign-nibble for a
data item without an "S" in the picture clause and allocate only 2 bytes of
storage. There also, is nothing in the Standard that says that this
couldn't actually take 4 (or more) bytes of storage, although I don't
personally know any vendor that does it that way.
Richard Plinston
>
> All COBOL compilers that support the '85 Standard *must* provide support for
> USAGE PACKED-DECIMAL. It is true that earlier Standards did not include
> this definition, and that, therefore, many vendors provide ALTERNATIVE
> syntax for packed-decimal data types. However, if you use USAGE
> Packed-Decimal syntax, you are GUARANTEED of source-code portability across
> '85 Standard (and later) compilers. Again, it is true that what this MEANS
> for each COBOL vendor may vary. The classic example is "unsigned -
> even-number of digit - Packed-Decimal items". If you have a data item
> defined as:
>
> 05 PD-1 Pic 9(4) Packed-Decimal.
>
> Some vendors "provide" a sign-nibble, thereby forcing this item to take 3
> bytes of storage - while other vendors do NOT require the sign-nibble for a
> data item without an "S" in the picture clause and allocate only 2 bytes of
> storage. There also, is nothing in the Standard that says that this
> couldn't actually take 4 (or more) bytes of storage, although I don't
> personally know any vendor that does it that way.
PACKED-DECIMAL may also be the same as DISPLAY NUMERIC on systems with
fewer bits than 8 in a 'byte'.
Ron
blaming COBOL because their language de jour cannot read
their data.